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ABSTRACT 


•^Tkis  thesis  presents  the  design  and  implerrentat  1  on  of 
the  Intelligence  Database  system.  A  database  management 
system  must  be  used  in  Intelligence  System  in  order  to 
increase  end-user  productivity,  decrease  staff  effort, 
enable  the  work  to  be  done  more  efficiently,  and  permit  end- 
user  management  more  authority  and  responsibility.  The 
Semantic  Database  Model  was  chosen  as  the  method  for 
designing  the  database.  The  SDM  is  a  high-level  semantics- 
based  database  description  and  structuring  formalism  for 
database  design  and  enhances  usability  of  database  system. 
Using  the  output  of  SDM  in  the  Intelligence  database,  the 
records  are  rearranged  in  order  to  fit  a  relational  DBMS. 
The  Intelligence  database  is  implemented,  using  the 
ORACLE  relational  DBMS.  ,x  j,  : 
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I .  IHTBQBSSTIQn 


It  is  obvious  that  it  is  the  database  system  era  in 
computer  technology  and  applications.  Database  processing 
has  grown  signif icantly  in  computer  science  areas  and  also 
in  management  of  certain  organizations. 

An  important  consideration  in  database  development  is 
to  store  data  in  such  a  way  that  it  can  be  used  for  a  wide 
variety  of  applications  and  can  be  changed  and  quickly 
and  easily.  To  achieve  the  flexibility  of  data  usage,  three 
aspects  of  database  design  and  implementation  are  important. 
First,  the  data  should  be  independent  of  each  other  and 
functionally  dependent  on  the  key  value.  Second,  it  should 
be  possible  to  interrogate  for  user's  requirements  using 
application  programs  or  the  DBMS  itself.  Third,  these  data 
items  should  provide  useful  information  for  decision  makers 
to  analyze,  to  investigate,  to  plan  and  to  manage  in  a 
certain  organi za tion . 

It  is  very  difficult  to  develop  database  systems  which 
perform  in  an  optimal  fashion.  There  are  many  different  ways 
n  which  data  can  be  structured  and  each  has  its  own 
advantages  and  disadvantages.  Different  users  want  to  use 
different  data/information.  It  is  hardly  possible  to  satisfy 
all  of  the  users  with  one  type  of  data  organizati on . 
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3.  IialualiOQ  A  CfiDfififiitial  fi£§igB 

What  makes  a  good  conceptual  design?  It  is 

possible  to  itemise  a  useful  set  of  properties  that 
characterise  a  good  conceptual  design  as  follows: 

*  Concept  complete  :  guarantees  not  only  that  useful 
objects  are  not  left  out  of  the  database  but  also  that 
physical  database  designers  are  not  inappropriately 
constrained.  It  is  true  that  for  many  derived  concepts 
the  derivation  can  only  be  made  in  one  direction. 

*  Unbiased  toward  applications  :  groupings  which  favor 
one  application  at  the  expense  of  others  should  be 
identified  and  removed  when  possible. 

*  Evolvable  :  it  should  be  locally  modifiable  and  it 
should  be  flexible  in  supporting  user  interpretations. 

*  Independence  of  existing  installation  and  DBMS 
constraints  :  initially  tailoring  a  design  to  fit  the 
limitation  of  the  current  state  of  its  intended  support 
system  makes  it  difficult  to  separate  out  these 
restrictions  when  the  support  system  changes  or  is 
replaced.  The  better  approach  is  to  develop  the  design 
independence  of  such  limitations  and  conventions  first, 
then  tailor  it  to  the  system. 

4 .  Design  Tool§  And  Methodologies 

The  primary  tool  in  database  design  is  the 
language  used  to  specify  the  design.  Such  a  specification 
language  is  a  tool  in  the  sense  that  its  vocabulary  and 


*  The  structure  of  the  database's  conceptual  objects 

*  The  structure  of  its  basic  functions  and  update 
procedures 

*  Integrity  constraints  on  the  database. 

The  conceptual  objects  of  a  database  are  all  very 
important  to  the  running  of  an  enterprise  whether  they  be 
people,  procedures,  events  or  the  inter-relationships  among 
these.  Such  objects  must  be  grouped  into  types  which 
identify  their  significant  attributes  and  processing 
constraints. 

Because  a  major  goal  of  database  management  is 
data  sharing,  it  is  expected  that  the  updates  of  each  user 
will  be  apparent  to  the  other  users  of  the  data.  This  makes 
it  import  ■•nt  that  the  necessary  side  effects  of  such  changes 
be  understood  and  correctly  implemented  by  all  application 
groups.  This  can  be  facilitated  by  including  in  the 
conceptual  design  specification  of  the  basic  update 
operatiors  for  objects  in  the  database. 

It  is  also  useful  for  the  onceptual  design  to 
include,  via  function  and  procedure  specification, 
conventions  for  naming  Individuals  that  exhibit  a  correct 
sensitivity  to  updates.  In  addition  to  the  integrity 
constraints  maintained  by  the  primitive  update  operations 
and  those  enforced  by  the  type  declarations,  there  may  be 
many  more  sophisticated  constraints  that  must  be  maintained 
for  the  database. 


necessary  to  support  the  various  application  views.  In 
effect,  conceptual  design  is  the  production  of  a  'community' 
model  in  which  the  idiosyncrasies  of  the  individual  views 
are  resolved.  At  the  conceptual  level,  data  should  appear  in 
a  structure  which  is  most  perspicuous  for  concept 
integration.  It  should  explicitly  define  how  concepts  are 
related  one  to  another?  it  should  not  contain  any 
implementation  detail;  and  it  should  be  locally  modifiable. 

The  final  phase,  'physical  design',  is  the  mapping 
of  the  conceptual  model  on  to  physical  computing  devices.  In 
this  phase,  performance  considerations  must  be  analyzed  and 
shown  compatible  with  application  requirements.  With  most 
database  management  systems,  the  uhysical  napping  is 
partially  hidden  and  'tuning'  is  allowed  on  only  a  fixed  set 
of  parameters. 

2 .  Tfce  Contents  Qf  A  Conceptual  Design 

The  conceptual  design  of  a  database  serves  two 
functions.  It  is  used  in  interactions  with  applications 
programmers  to  verify  the  correctness  of  the  program  being 
developed.  It  is  also  used  as  a  guideline  for  the  physical 
designers  -  specifying  to  them  what  must  be  implemented 
without  constraining  how  it  is  Implemented.  To  achieve  these 
objectives  the  following  kinds  of  information  must  be 
determined  in  the  design  process: 


A  database  must  encompass  all  aspects  of  the  data 
to  he  stored  -  beginning  with  details  of  how  it  is  presented 
to  different  users  and  ending  with  how  it  is  to  be 
represented  on  the  hardware  of  a  particular  installation.  To 
achieve  this  in  an  orderly  and  correct  fashion,  the  design 
process  has  been  structured  into  the  three  distinct  phases 
shown  in  Figure  3.1.  The  first  phase,  which  may  be  called 
'view  design',  is  the  identification  and  design  of 
interfaces  for  the  different  end-user  groups.  Each  end  user 
requires  a  particular  'view'  of  the  database  to  support  his 
own  application  idiosyncrasies.  A  view  should  present  data 
in  the  structure  which  is  most  effective  for  the  user.  This 
may  be  reports,  natural  language  text.  The  view  must  provide 
tailored  update  facilities  to  manipulate  the  database. 


!  Application  !  *  j  Application  i  View 

i  View  !  !  View  ! 

-  -  Design 
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Figure  3.1  Phases  in  Database  Design 


III.  INTgQfigCJiQN  IQ  QAIA£A5£  £3SIG£j 


A.  CONCEPTUAL  DATABASE  DESIGN 

Database  Management  Systems  have  evolved  from  file 
systems  to  answer  two  critical  needs:  support  for  more 
Inter-related  data  and  support  for  sharing  data  among  many 
diverse  applications.  These  goals  are  being  achieved,  in 
part,  by  providing  DBMS  software  to  physically  link  related 
data  into  complex  structures  using  such  mechanisms  as 
pointer  chains,  indices  and  sequential  positioning.  They  are 
also  achieved  by  the  development  of  database  design 
methodologies  and  rules. 

To  reduce  the  complexity  of  using  DBMSs,  designers  have 
developed  special  interfaces  to  these  systems  that  decompose 
their  use  into  easily  underst * -d  phases.  Thus,  most  DBMSs 
have  Data  Description  Languages  (DDLs),  Data  Manipulation 
Languages  (DMLs )  and  Query  Languages.  The  DDL  is  used  to 
specify  the  design  of  the  database.  The  DML  is  used  to 
generate  application  programs  that  access  the  database  in 
terms  of  the  objects  specified  using  the  DDL.  The  Query 
Language  is  used  for  more  'casual'  database  accesses.  The 
DML  is  orinted  toward  the  development  of  database  access 
programs  that  are  efficient  to  execute  while  Query  Languages 
are  orinted  towards  ease  in  writing  such  programs. 


the  same  data  so  that  applications  can  use  data  in  a  format 
that  is  familiar  and  useful  to  them. 

The  DBMS  also  has  features  to  provide  security  over 
data;  the  tools  provided  ensure  that  only  authorized  data 
are  accessed.  Also,  the  DBMS  controls  concurrent  processing 
and  includes  features  to  provide  backup  and  recover. 

The  final  type  of  program  involved  in  database 
processing  is  the  operating  system.  This  set  of  programs 
controls  the  computer's  resources.  The  DBMS  sends  requests 
for  Input/output  services  to  operating  system. 


User 

Processing  Computer 

(Online 

Main  Memory  i - - — 

Processing) 

1 

1 

1 

1 

1 

Database 

Figure  2.2  Programs  Involved  in  Typical 
Database  Processing 
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DBMS  intercepts  the  request  and  interprets  it?  (3)  the  DBMS 
inspects,  in  turn,  the  exte  nal  schema,  the 
external/conceptual  mapping,  the  conceptual  schema,  the 
conceptual/internal  mapping,  and  the  storage  structure 
definition;  and  (4)  the  DEMS  performs  the  necessary 
operations  on  the  stored  database. 

D.  PROGRAMS  IN  TYPICAL  DATABASE  PROCESSING 

Figure  2.2  shows  the  approximate  relationships  of  the 
major  types.  Online  processing  requests  or  transactions  are 
provided  hy  users  at  terminals.  The  requests  are  sent  to 
the  processing  computer  over  communications  lines. 

The  communications  control  program  (CCP)  has  several 
important  functions.  It  provides  comunications  error 
checking  and  correction,  coordinates  terminal  activity, 
routes  messages  to  the  correct  next  destination,  and 
formats  messages  for  various  types  of  terminal  equipment. 

The  utility  programs  are  provided  by  either  the  DBMS  or 
the  hardware  vendor.  These  programs  provide  a  wide  variety 
of  services.  Query/update  utilities  provide  generalized 
retrieval  and  update  of  the  database. 

For  normal  processing,  the  DBMS  receives  data  and 
stores  it  for  subsequent  processing.  This  system  acts  as  a 
sophisticated  data  librarian.  The  DBMS  allows  application 
programs  and  utilities  a  wide  variety  of  access  strategies. 
It  also  enables  these  programs  to  have  different  views  of 


sequence,  indexing,  hash-addressing,  or  any  other  storage/ 
access  details.  The  conceptual  model  is  a  view  of  the  total 
database  content,  and  the  conceptual  schema  is  a  definition 
of  this  view.  The  definition  in  the  conceptual  schema  is 
intended  to  include  a  great  many  additional  features,  such 
as  the  authorization  checks  and  validation  procedures. 

The  internal  model  is  a  very  low-level  representation 
of  the  entire  database;  it  consists  of  multiple  occurrences 
of  multiple  types  of  internal  records.  The  internal  model  is 
described  by  means  of  the  internal  schema,  which  not  only 
defines  the  various  types  of  stored  records  but  also 
specifies  what  indexes  exist,  how  stored  fields  are 
represented,  what  physical  sequence  the  stored  records  are 
in,  etc. 

The  conceptual/internal  mapping  defines  the 
correspondence  between  the  data  model  and  the  store.d 
database;  it  specifies  how  conceptual  records  and  fields  map 
into  their  stored  counterparts.  If  the  structure  of  the 
stored  database  is  changed  -  if  a  change  is  made  to  the 
storage  structure  definition  -  the  conceptual/internal 
mapping  must  be  changed  accordingly,  so  that  the  conceptual 
schema  may  remain  invariant. 

The  Database  Management  System  is  the  software  that 
handles  all  access  to  the  database.  Conceptually  what 
happens  is  the  following  :  (1)  A  user  issues  an  access 
request,  using  some  particular  data  sublanguage;  (2)  the 


Next,  the  various  components  of  the  system  will  he 
examined.  The  users  are  either  application  programmers  or 
remote  terminal  users  of  any  degree  of  sophistication.  Each 
user  has  a  language  at  his  disposal.  It  will  he  a 
conventional  programming  language,  such  as  COBOL,  PL/1,  etc. 

Each  user  is  provided  with  a  workspace,  which  acts  as 
the  receving  or  transmitting  area  for  all  data  tranferred 
between  the  user  and  the  database.  The  user  is  said  to  view 
the  database  by  means  of  an  external  model.  An  external 
model  is  thus  the  information  content  of  the  database  as  it 
is  viewed  by  some  particular  user. 

Each  external  model  is  defined  by  means  of  an  external 
schema,  which  consists  of  descriptions  of  each  of  the 
various  types  of  eiternal  records  in  that  external  model.  In 
addition,  there  must  be  a  definition  of  the  mapping  between 
the  external  schema  and  the  undering  conceptual  schema. 

The  conceptual  model  is  a  representation  of  the  entire 
information  content  of  the  database,  again  in  a  form  that  is 
somewhat  abstract  in  comparison  with  the  way  in  which  the 
data  is  physically  stored.  The  conceptual  model  is  defined 
by  means  of  the  conceptual  schema,  which  includes 
definitions  of  each  of  the  various  types  of  conceptual 
records.  If  data  independence  is  to  be  achieved,  these 
definitions  must  not  involve  any  considerations  of  storage 
structure  or  access  strategy.  Thus  there  must  be  no 
reference  to  stored  field  representations,  physical 
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proposed  by  the  ANSI/SPARC  Study  Group  on  Data  Ease 

Management  Systems.  The  architecture  Is  divided  into  three 

general  levels:  internal,  conceptual,  and  external.  Eroadly 

speaking,  the  internal  is  the  one  closest  to  physical 

storage,  the  one  concerned  with  the  way  in  which  the  data  is 

actually  stored;  the  external  level  is  the  one  closest  to 

the  users,  that  is,  the  one  concerned  with  the  way  In  which 
% 

the  data  is  viewed  by  individual  users;  and  the  conceptual 
level  is  a  'level  of  indirection'  between  the  other  two. 


Schema*  and 
maobintjt  built 
and  maintained 
by  the 
database 
administrator 
(OBAI 


V. 


*Uier  interlace 


Figure  2.1  An  Architecture  for  a  Database  System 
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implemented,  operating  costs  for  some  systems  will  be 
higher.  Sequential  processing,  for  example,  will  never  be 
done  as  fast  as  in  the  database  environment,  because  of  the 
extra  overhead. 

Another  disadvantage  is  that  database  processing 
tends  to  be  complex.  Large  amounts  of  ata  in  many  different 
formats  can  be  interrelated  in  the  database.  Both  the 
database  system  and  the  application  programs  must  be  able  to 
process  these  structures.  This  requires  more  sophisticated 
programming.  Backup  and  recovery  are  more  difficult  in  the 
database  environment.  This  is  because  of  increased 
complexity  and  because  the  database  is  often  processed  by 
several  users  concurrently.  Determining  the  exact  state  of 
the  database  at  the  time  of  failure  may  be  a  problem.  Given 
that,  it  may  be  even  more  difficult  to  determine  what  should 
be  done  next. 

The  third  disadvantage  is  that  integration,  and 
hence  centralization,  increases  vulnerability.  A  failure  in 
one  component  of  an  integrated  system  can  stop  the  entire 
system.  This  event  is  especially  critical  if,  as  is  often 
the  case,  the  operation  of  the  user  organization  depends  on 
the  database. 

C.  AN  ARCHITECTURE  FOR  A  DATABASE  STSTEM 

The  architecture  of  a  database  is  outlined  in  Figure 
2.1  [Ref.  4].  This  figure  is  in  broad  agreement  with  that 


i •  2i  Ciiiiass 

First,  database  processing  enables  more 
information  to  be  produced  from  a  given  amount  of  data. 
Second,  the  elimination  or  reduction  of  data  duplication 
saves  file  space,  and  to  some  extent,  can  reduce  processing 
requirements.  The  most  serious  problem  of  data  duplication 
is  that  it  can  lead  to  a  lack  of  data  integrity.  A  common 
result  of  a  lack  of  data  integrity  is  conflicting  reports. 
Third,  creation  of  program/data  independence  -  the  immunity 
of  applications  to  change  in  storage  structure  and  access 
strategy,  which  implies  that  the  application  concerned  do 
not  depend  on  any  one  particular  storage  structure  and 
access  strategy.  Another  advantage  is  better  data 
management.  When  data  is  centralizied  in  a  database,  one 
department  specializes  in  the  maintenance  of  data.  That 
department  can  specify  data  standards  and  ensure  that  all 
data  adhere  to  the  standards.  When  someone  has  a  data 
requirement,  he  can  contact  one  department  instead  of  many 
file  maintenance  groups.  F  rthermore,  centralization  of  data 
management  leads  to  economies  of  scale. 

2.  Disadvantage  of  Eatajjasg 

A  major  disadvantage  of  database  is  that  it  can  be 
expensive.  The  DEMS  may  occupy  so  much  main  menory  that 
additional  memory  must  be  purchased.  Even  with  more  memory, 
it  may  monopolize  the  CPU,  thus  forcing  the  user  to  upgrade 
to  a  more  powerful  computer.  Once  the  database  is 
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II.  BASIC  CO&CE£T  e|  DATABASE 


A.  WHAT  IS  A  DATABASE? 

First  of  all,  there  is  the  database  itself  -  a 
collection  of  data  stored  on  disks,  drums  or  other  secondary 
storage  media.  Second,  there  is  a  set  of  ordinary  batch 
application  programs  which  run  against  this  data,  operating 
on  it  in  all  the  usual  ways.  Third,  the  database  is 
"integrated'.  This  means  that  the  data  base  contains  the 
data  for  many  users,  not  Just  for  one,  which  in  turn  implies 
that  any  one  user  will  be  concerned  with  just  a  small 
portion  of  it.  According  to  [Ref.  4],  the  definition  of 
database  is  a  collection  of  stored  operational  data  used  by 
the  application  systems  of  some  particular  enterprise.  Some 
examples  of  enterprise  are  manufacturing  companies,  banks, 
hospitals,  etc. 


B.  WHY  DATABASE? 

There  are  many  answers  to  this  question.  Cne  general 
answer  is  that  it  provides  the  enterprise  with  centralized 
control  of  its  operational  data.  This  is  in  sharp  contrast 
to  the  situation  that  prevails  in  most  enterprises  today, 
where  typically  each  application  has  its  own  private  files 
so  that  the  operational  data  is  widely  dispersed,  and  there 
is  little  or  no  attempt  to  control  it  in  a  systematic  way. 


The  normal  form  concepts  of  relational  database  will  he 
used  to  develop  an  Intelligence  Database,  because  the 
Relational  Database  Management  System  supports  Independence 
better  than  other  models  and  is  easLer  to  Implement. 

Chapter  II  addresses  the  basic  concepts  of  database, 
which  relates  to  the  database  system  development  for  the 
Intelligence  Database.  Chapter  III  addresses  the 
introduction  to  database  design,  which  includes  conceptual 
database  design  and  physical  database  design.  Chapter  IV 
describes  how  the  Intelligence  Database  is  designed  using 
Semantic  Database  Model.  First  of  all,  the  SDM  is  designed; 
then  a  relational  or  network  model  is  applied  and 
implemented.  Chapter  V  describes  Relational  database 
design,  which  includes  relational  Normal  Forms  and  the 
characteristics  of  relational  database  and  conversion  of  SDM 
into  Relational  database  design.  Chapter  VI  addresses  the 
implementation  which  is  implemented  on  the  ORACLE  Database 
Management  System.  Finally,  Chapter  VII  presents  conclusion 
and  recommendations  based  on  the  research  presented  in  the 
thesis . 
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syntax  shapes  the  way  designers  percieve  the  application 
they  are  modelling.  A  model  too  primitive  in  its  vocabulary 
requiries  more  complicated  concepts  to  be  built  up, 
producing  a  specif ication  that  is  difficult  to  understand 
and  therefore  to  use  and  to  verify. 

Each  of  the  following  properties  contribute  to 
value  of  a  good  data  model  : 

1.  It  should  be  expressive  :  a  data  model  that  is 
sensitive  to  important  distinctions  will  guide  its 
users  to  include  the  concepts  and  objects  necessary  to 
a  good  design. 

2.  It  should  not  over  constrain  implementors  :  because  a 
conceptual  design  is  the  mechanism  used  to  instruct 
physical  database  implementors  the  model  on  which  it  is 
based  should  not  imply  particular  implementation 
strategies . 

3.  A  data  model  should  have  a  formal  basis:  this  relieves 
the  designer  of  ambiguity  and  provides  the  physical 
designers  and  implementors  with  a  sound  foundation  for 
verifying  their  work. 

4.  A  data  model  should  be  widely  applicable:  A  conceptual 
design  for  an  extensive  enterprise  may  need  to 
encompass  applications  that  are  very  dynamic  in  terms 
of  interactions  among  the  different  objects  of  interest 

5.  A  data  model  should  be  understandable  :  A  conceptual 
design  for  an  extensive  enterprise  can  be  both  very 


large  and  very  complex.  To  show  even  a  part  ot  a 
specification  to  an  end  user  to  check  its  correctness, 
it  is  necessary  that  the  data  model  in  which  it  is 
expressed  provides  some  kind  of  non~technical 
presentation  mode. 

5*  Implemen£aii£n  Cgsiga  £2DESa«liS 

A  diagram  of  the  spectrum  of  inputs  to  and  outputs  from 
implementation  design  is  shown  in  Figure  3.2, 
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Inputs  are  as  follows; 

1.  DB'dS-independent  schema  -  The  major  result  of  the 
conceptual  design  phase,  to  be  refined  by  the 
implementation  design  phase. 

2.  Operational  requirements  quantification  -  Specification 
for  integrity,  recovery,  security,  and  response  tire 
limits . 

3.  Volume  and  usage  quantification  -  Database  si2e  in 
terms  of  data  occurences  and  application  frequencies. 

4.  Consistency  constraints  -  Rules  for  Keeping  data 

elements  consistent,  rules  for  dealing-  with 

inconsistent  data. 

Outputs  are  as  follows; 

1.  DBMS-processible  schema  -  Specifications  for  a  database 
structure  that  can  be  implemented  with  a  specific  r?MS. 

2.  Subschemas  -  DEMS-processible  database  structure 
consistent  with  individual  user  views  and  security 
constraints . 

3.  Guidance  to  the  database  operations  group  -  a  summary 
of  requirements,  constraints,  and  available  data  or  the 
hardware/software  environment  to  the  DBA. 

B.  PHYSICAL  DATABASE  DESIGN 

The  second  stage  of  database  design  -physical  design- 
is  a  stage  of  transformation.  The  logical  schema  is 
tranformed  into  the  particular  data  constructs  that  are 
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available  with  the  DBMS  to  he  used.  Whereas  the  logical 
design  is  DBMS-independent,  the  physical  design  is  very  much 
DBMS-dependent.  Detailed  specifications  of  the  datatase 
structure  are  produced.  These  specifications  will  he  used 
during  implementation  to  write  source  statements  that  define 
the  database  structure  to  the  DBMS.  These  statements  will  he 


compiled  by  the  DBMS  and  the  object  form  of  the  database 
structure  will  be  stored  within  the  database.  as 
illustrated  in  Figure  2.3.  [Ref.  3] 
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Figure  3.4  Physical  Environment 

In  general,  physical  design  considers  new 
parameters,  but  previous  tentative  decisions  on  access 
paths  and  record  allocation  are  finalized  in  this  phase. 
Parameters  regarding  data  volume,  application  processing 
frequency,  and  sequence  of  operations  in  aplication  programs 
are  the  same  as  those  required  for  implementation  design. 
New  parameters  introduced  at  this  stage  are  those  specific 
to  DBMS  and  operating  system  access  methods,  those  specific 
to  describe  physical  device  capacity  limitations  and  timing 
characteristics  and  all  operational  requirements. 

The  visible  components  of  the  resulting  physical 
database  structure  are  the  stored  record  format,  stored 
record  placement  specification,  and  access  method 
specification.  Underlying  these  specifications  is  the 
satisfaction  of  all  operational  requirements  and 


hardware/software  system  constraints.  During  the  design 

process,  consideration  of  efficiency  issues  can  taice  place 
only  after  the  various  constraints  arp  satisfied  and  a 
feasible  solution  has  been  obtained. 

2.  Performansg  Measure 

The  determination  of  performance  measures  for 
physical  design  is  most  critical  to  the  design  process.  It 
affects  not  only  the  design  choices,  but  also  the 
techniques  employed  to  determine  those  choices. 

Let  us  assume  that  database  system  performance 

will  be  described  in  terms  of  cost.  At  various  times  cost 

may  be  given  in  terms  of  time,  space,  or  possibly  monetary 
value.  Returning  to  our  discussion  of  the  database  system 

life  cycle,  we  can  describe  the  total  cost  of  the  life  cycle 
in  terms  of  the  following: 

*  Planning  cost 

*  Design  cost  :  programs,  database 

*  Implementation  and  testing  cost  :  programs,  databases 

*  Operational  costs  :  users,  compute  resource 

*  Maintenance  costs  :  program  errors,  data  integrity 
loss 

3 .  Output^  of  Physical  Design 

In  general,  two  major  specifications  are  produced. 
First,  the  physical  specification  of  the  logical  schema  is 
defined.  It  is  the  physical  schema.  This  schema  is  a 
transformation  of  the  logical  schema  into  the  data  modeling 


constructs  available  with  the  DBMS  to  he  used.  Second,  user 
views  are  defined. 

a.  Physical  schema 

The  contents  of  records  must  he  defined,  and 
the  name  and  format  of  each  field  of  each  record  specified. 
Constraints  from  the  logical  database  design  are  tranformed 
into  critiria  for  field  descriptions.  Keys  of  database 
records  need  to  he  identified,  acid  overhead  structures  for 
supporting  the  keys  defined.  Record  relationships  are  also 
defined  in  the  physical  design. 

b.  User  views 

User  views  are  generally  a  subset  of  the 
schema.  Records  or  relationships  may  be  omitted  from  a  view; 
fields  may  be  omitted  or  rearranged.  Also,  the  names  of 
records,  fields,  or  relationships  may  be  changed.  This 
flexibility  allows  users  to  employ  terminology  that  is 
familiar  and  useful  to  them. 

C.  APPLICATION  0?  DATABASE  MODELS  TO  DATABASE  DESIGN 

Figure  3.5  shows  the  major  steps  involved  in 
designing  a  database.  Inputs  to  design  are  statements  of 
data  requirements  from  the  specification  data  directory.  The 
output  of  design  is  a  specification  that  can  be  used  to 
implement-  the  database  using  a  commercial  DBMS.  The  design 
that  is  produced  depends  very  much  on  the  DBMS  to  be 
employed.  For  this  reason,  Figure  3.5  shows  two  alternative 
design  outputs.  If  we  are  going  to  use  a  DENS  based  on  the 
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relational  model,  we  will  produce  a  relational  design.  If 
we  are  going  to  use  a  DBMS  based  on  the  CODASYL  DBTG  model, 
we  will  produce  a  DBTG(network)  design. 

Within  this  figure  are  two  steps  :  1 ogi cal ( DBMS 
independent)  design  and  physical (DBMS  -  dependent)  design. 
After  logical  design,  there  is  a  branch,  depending  on  the 
DBMS  to  be  employed.  If  we  are  going  to  use  a  relational 
DBMS,  then  the  output  of  physical  design  will  be  a 
relational  design  expressed  as  relation  definitions  and 
supporting  documentation. 

If  we  are  going  to  use  a  CODASYL  DBMS,  then  the  output 
of  the  physical  design  will  be  a  CODASYL  design  expressed  as 
data  structure  diagrams  and  supporting  definitions. 


IV.  SIM ANTIC  DATABASE  MODEL 

The  Semantic  Database  Model(SDM)  was  developed  by 
Hammer  and  McLed  [Ref.  8]  and  first  published  in  1S81.  It 
will  be  used  as  the  tool  for  expressin  a  logical  schema  for 
the  Intelligence  database  design. 

SDM  is  a  high-level  sema.nti  cs-based  database 
description  and  structuring  formalism  for  the  database.  This 
database  model  is  designed  to  capture  more  of  the  meaning  of 
an  application  environment  than  is  possible  with 
contemporary  database  models. 

SDM  is  designed  to  enhance  the  effectiveness  and 
usability  of  database  systems.  An  SD^  database  description 
can  serve  as  a  formal  specification  and  documentation  tool 
for  a  database.  It  can  provld_e  a  basis  for  supporting  a 
variety  of  powerful  user  interface  facilities,  serve  as  a 
conceptual  database  model  in  the  database  design  process, 
and  be  used  as  the  database  model  for  a  new  kind  of  database 
management  system. 

A.  INTRODUCTION 

Every  database  is  a  model  of  some  real  world  system.  At 
all  times,  the  contents  of  a  database  are  intended  to 
represent  a  snapshot  of  the  state  of  an  application 
environment,  and  each  change  to  the  database  should  reflect 
an  event  occuriDg  in  that  environment.  Therefore,  it  is 
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appropriate  that  the  structure  of  a  database  mirror  the 
structure  of  the  system  that  it  models.  4  database  whose 
organization  is  based  on  naturally  occurring  structure  will 
be  easier  for  a  database  designer  to  construct  and  modify 
than  one  that  forces  him  to  translate  the  primitives  of  his 
problem  domain  into  artificial  specification  constructs. 

The  global  user  view  of  a  database,  as  specified  by  the 
database  designer,  is  known  as  its  logical  schema.  A  schema 
is  specified  in  terms  of  a  database  description  ard 
structuring  formalism  and  associated  operations,  called  a 
database  model.  It  was  thought  that  the  data  structures 
provided  by  contemporary  database  models  do  not  adequately 
support  the  design,  evolution,  and  use  of  a  complex 
database.  These  database  models  have  significantly  limited 
capabilities  for  expressing  the  meaning  of  a  database  ar.d 
relating  a  database  to  its  corresponding  application 
environment.  The  semantics  of  a  database  defined  in  terms 
of  these  mechanisms  are  not  readily  apparent  from  the 
schema;  Instead,  the  semantics  must  be  separately  specified 
by  the  database  designer  and  consciously  applied  by  the 
user . 

The  goal  is  the  design  of  a  higher-level  databas0  model 
that  will  enable  the  database  designer  to  naturally  and 
directly  incorporate  more  of  the  semantics  of  a  database 
into  its  schema.  Such  a  semantics-based  database  description 
and  structuring  formalism  is  intended  to  serve  as  a  natural 


application  modeling  mechanism  to  capture  and  express  the 
structure  of  the  application  environment  in  the  structure  of 
the  database. 

1 .  Tije  Design  of  SDM 

In  designing  SDM,  many  database  aplications  were 
analyzed  in  order  to  determine  the  structures  that  cccur 
and  recur  in  them.  The  shortcomings  of  contemporary 
database  models  in  capturing  the  semantics  of  these 
applications  were  assessed,  and  the  strategies  were 
developed  to  address  the  problems  discovered.  This  design 
process  was  iterative,  In  that  features  were  removed,  added, 
and  modified  during  various  stages  of  esign. 

SDM  has  been  designed  with  a  number  of  specific 
types  of  uses  in  mind.  First,  SDW  is  meant  to  serve  as  a 
formal  specification  mechanism  for  describing  the  meaning  of 
a  database:  SDM  provides  a  precise  documentation  and 
communication  medium  for  database  users.  In  particular,  a 
new  user  of  a  large  and  complex  database  should  find  its  SDM 
schema  of  use  In  determining  what  information  is  contained 
in  the  database.  Second,  SDM  provides  the  basis  for  a 
variety  of  high-level  semantics-based  user  interfaces  to  a 
database;  these  interface  facilities  can  be  constructed  as 
front-ends  to  existing  database  management  systems. 

SDM  has  been  designed  to  satisfy  a  nurber  of 
criteria  that  are  not  met  by  contemporary  database  models, 


but  which  I  believe  to  be  essential  in  an  effective  database 
description  and  structuring  f ormalism .  They  are  as  follows. 

The  constructs  of  the  database  model  should  provide 
for  the  explicit  specification  of  a  large  portion  of  the 
meaning  of  a  database.  Many  contemporary  database  models 
(such  as  the  COEASYL  EBTG  network  model  and  the  hierachical 
model)  exhibit  compromises  between  the  desire  to  provide  a 
user-oriented  database  organization  and  the  need  to  support 
efficient  database  storage  and  manipulation  facilities.  In 
contrast,  the  relational  database  model  stresses  the 
separartion  of  user-level  database  specification  and 
underlying  implementation  detail. 

However,  the  Semantic  expressiveness  of  the 
hierachical,  network,  and  relational  model  is  limited;  they 
do  not  provide  sufficient  mechanism  to  allow  a  database 
schema  to  describe  the  meaning  of  a  database.  Such  models 
employ  overly  simple  data  structures  to  model  an  application 
environment.  In  so  doing,  they  lose  information  about  the 
database;  they  provide  for  the  expression  of  only  a  limited 
range  of  a  designer's  knowledge  of  the  application 
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the  meaning  of  a  database,  and  allow  the  structure  cf  e 


37 


database  to  support  alternative  ways  of  looking  at  the  same 
information.  In  order  to  accommodate  multiple  views  cf  the 
same  data  and  to  enable  the  evolution  of  new  perspectives  on 
the  data,  a  database  model  must  support  schema  that  are 
flexible,  potentially  logically  redundant,  and  integrated. 
Flexibility  is  essential  in  order  to  allow  for  multiple  and 
coequal  views  of  the  data. 

Contemporary,  record-oriented  database  models  do 
not  adequately  support  relativism.  In  these  models,  it  is 
generally  necessary  to  impose  a  single  structural 
organization  of  the  data,  one  which  inevitably  carries  along 
with  it  a  particular  interpretation  of  the  data's  meaning. 
This  meaning  may  not  be  appropriate  for  all  users  of  the 
database  and  may  become  entirely  obsolete  over  time. 

Another  consequence  of  the  primacy  cf  the 
principle  of  relativism  is  that,  in  general,  the  database 
model  should  not  make  rigid  distinctions  between  such 
concepts  as  entity,  association,  and  attribute.  Higher-level 
database  models  that  do  require  the  database  schema 
designers  to  sharply  distinguish  among  these  concepts  are 
thus  considered  somewhat  lacking  iu  their  support  of 
relat iv ism. 

A  database  model  must  support  the  definition  o' 
schemata  that  are  based  on  abstraction  entities. 
Specifically,  this  means  that  a  database  model  must 
facilitate  the  description  cf  relevant  entities  in  the 
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application  environrent,  collections  of  such  entities, 
relationships  among  entities,  and  structual  inter¬ 
collections  among  the  collections. 

Allowing  entities  to  represent  themselves  makes  it 
possible  to  directly  reference  an  entity  from  a  related  one. 
In  record-oriented  database  models,  it  is  necessary  to  cress 
reference  between  related  entities  by  means  of  their 
identifiers.  While  it  is  of  course  necessary  to  eventually 
represent  'abstract'  entities  as  symbols  inside  a  computer, 
the  point  is  that  users  should  be  able  to  reference  and 
manipulate  abstractions  as  well  as  symbols. 

B.  A  SPECIFICATION  OF  SDPI 

The  following  general  principles  of  database 

organization  underlie  the  design  of  SDM  [Ref.  3].’ 

(1)  A  database  is  to  be  viewed  as  a  collection  of  entities 

that  correspond  to  the  actual  objects  in  the 

application  environment 

(2)  The  entities  of  a  database  are  organized  into  CLASS'S 
that  are  meaningful  collections  of  entities. 

(3)  The  classes  of  a  database  are  not  in  general 

independent,  but  rather  are  logically  related  by  mra  rc 
of  Interclass  connections. 

(4)  Database  entities  and  classes  have  ATT  I  HI EUTFS  that 
describe  their  characteristics  and  relate  them  to 
other  database  entities.  An  attribute  value  may  be 
derived  from  other  values  in  the  database. 
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select  representations  for  these  constructs  in  a  routine,  if 
not  algorithmic,  fashion. 

SDM  provides  an  effective  base  for  accommcda t ing 
the  evolution  of  the  content  structure  and  use  of  a 
database.  Relativism,  logical  redundancy,  and  derived 
lnfomation  support  this  natural  evolution  of  the  schema. 

A  related  use  of  SDh*  is  as  a  medium  for 
documenting  a  database.  One  of  the  more  serious  problems 
facing  a  novice  user  of  a  large  database  is  determining  the 
information  content  of  the  database  and  locating  in  the 
schema  the  information  of  use  to  him.  An  SEP  schema  for  a 
database  can  serve  as  a  readable  description  of  its 

contents,  organized  in  terms  that  a  user  is  likely  to  be 
able  to  comprehend  and  identify. 


schema  using  the  database  model  of  the  DBMS  to  be  employed, 
is  a  difficult  and  error-prone  procedure.  A  primary  reason 
for  this  difficulty  is  the  gap  between  the  semantic  level  of 
the  application  and  the  data  structures  of  the  database 
model;  the  DEA  must  bridge  this  gap  in  a  single  step, 
simultaneously  conducting  an  information  requirements 
analysis  and  expressing  the  results  of  his  analysis  in  terms 
of  the  database  model. 

1 •  The  Advan tage  Of  SDM 

An  SDM  schema  will  serve  as  a  specif ication  of  the 
information  that  the  database  will  contain.  All  too  often, 
only  the  most  vague  and  amorphous  English  language 
descriptions  of  a  database  exist  prior  to  the  database 
design  process.  A  formal  specification  can  more  accurately, 
completely,  and  consistently  communicate  to  the  actual 
designer  the  prescribed  contents  of  the  database.  $!>' 
provides  some  structure  for  the  logical  database  design 
process.  The  DBA  can  first  seek  to  describe  the  database  ir. 
high-level  semantic  terms,  and  then  reduce  that  schema  to  a 
more  conventional  logical  design. 

SDM  supports  a  basic  methodology  that  ran  guide 
the  DBA  in  the  design  process  by  providing  him  with  a  set  of 
natural  design  templates.  That  is,  the  DBA  can  approach  the 
application  in  question  with  the  intent  of  identifying  its 
classes,  subclasses,  and  so  on.  Having  done  so,  he  can 


available  for  describing  attributes  that  d  not  match  any  of 
these  cases.  Tor  example,  Total-foe  is  derived  from  IREC 
record  by  calculating  total  number  of  foes. 

2.  Clajs  4!irlbui£  Lsi!Uielaiion£&iES 

Attribute  derivation  primitives  analogous  to 
primitives  for  member  attributes  can  be  used  to  define 
derived  class  attributes,  as  these  primitives  derive 
attribute  values  from  those  of  other  attributes.  In 
addition,  there  are  two  other  primitives  that  can  be  used  in 
the  definition  of  derived  class  attributes. 

(1)  An  attribute  can  be  defined  so  that  its  value 
equals  the  number  of  members  in  the  class  it  modifies.  Eor 
example.  Total-foe  has  the  derivation  'number  of  members  in 
this  class'. 

(2)  an  attribute  can  be  defined  whose  value  is  a 
function  of  a  numeric  member  attribute  of  a  class;  the 
functions  supported  are  'maximum',  'minimum',  'average'. 

D.  APPLICATION 

SDM  is  simply  an  abstract  database  modeling  mechanism 
and  language  that  is  not  dependent  on  any  supporting 
computer  system.  One  set  of  applications  uses  in 
precisely  this  mode  to  support  the  process  of  defining  and 
designing  a  database  as  well  as  in  facilitating  its 
subsequent  evolution.  It  is  well  known  that  the  process  of 
logical  database  design,  wherein  the  DSA  must  construct  a 


If  A1  is  a  multivalued  attribute,  then  it  is 
permissible  for  each  member  of  Cl  to  match  to  several 
members  of  C2;  in  this  case,  the  collection  of  A3  values  is 
the  value  of  attribute  Al.  For  example,  Iclass/Itype  is 
matched  with  Pclass/Ptype  (Figure  4.3). 

Therefore,  match  is  defined  only  in  IRIC 
record  and  not  defined  in  PPEC  record.  That  means,  according 
to  PID,  Pclass/Ptype  is  matched  and  the  value  is  updated. 

Inversion  and  matching  provide  multiple  ways 
of  viewing  n-ary  associations  among  entities.  Inversion 
permits  the  specification  of  binary  associations,  while 
matching  is  capable  of  supporting  binary  end  higher  degree 
associations. 

c.  Derivation 

Inversion  and  matching  are  mechanisms  for 
eastablishing  the  equivalence  of  different  ways  of  viewing 
the  same  essential  relationships  among  entities.  SDP  also 
provides  the  ability  to  define  an  attribute  whose  value  is 
calculated  from  other  information  in  the  database.  ?uch  an 
attribute  is  called  Derived,  and  the  specification  of  its 
computation  is  its  associated  derivation. 

The  approach  is  to  provide  a  small  vocabulary 
of  high-level  attribute  derivation  primitives  that  directly 
model  the  most  common  types  of  derived  information.  Each  of 
these  primitives  provides  a  way  of  specifying  one  method  of 
computing  a  derived  attribute.  Pore  general  facilities  are 
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attribute  A1  of  class  Cl  can  be  specified  as  the  inverse  of 

member  attribute  A2  of  C2  which  means  that  the  value  of  M 

for  a  member  Ml  of  Cl  consists  of  those  members  of  C2  whose  *-1 

value  of  A2  is  Ml.  The  inversion  Interattribute  relationship 

is  specified  symmetrically  in  that  both  an  attribute  and  its  ;>-1 

inverse  contain  a  description  of  the  inversion 

relationship.  A  pair  of  inverse  attributes  in  effect  •/- 

establish  a  binary  association  between  the  members  of  the 

classes  that  the  attributes  modify.  For  example,  Wammo  in  ‘  ; 

WREC  record  has  inverse  relationship  with  Where-needed  in 

AREC  record. 

w-'J 

Therefore,  value  class  and  inverse  is  defined  : 

in  Wammo  and  another  item  name  is  defined  in  AREC  record, 
which  corresponds  to  Wammo  item  name. 

— 

b.  Matching 

The  second  way  in  which  a  member  attribute  .-1 

can  be  related  to  other  information  in  the  databas®  is  by 
matching  the  value  of  the  attribute  with  some  member  of  a 
specified  class.  In  particular,  the  value  of  the  mateh  v; 

attribute  A1  for  the  member  Ml  of  class  Cl  Is  determined  as  " 

follows. 

(1)  A  member  M2  of  some  class  C2  is  found  that  has  mi  as 
Its  value  of  member  attribute  A2. 

“  -r- 

(2)  The  value  of  member  attribute  A3  for  M2  is  used  as  the  v; 


value  of  A1  for  Ml. 


(4)  An  (optional)  ATTRIBUTE  DESCRIPTION  is  text  that 
describes  the  meaning  and  purpose  of  the  attribute. 

(5)  The  attribute  is  specified  as  either  SINGLE  VALUED  or 
MULTIVALUED.  The  value  of  a  s ingl e-velued  attribute  is 
a  member  of  the  value  class  of  the  attribute,  while 
the  value  of  a  multivalued  attribute  is  a  subclass  of 
the  value,  (e.g.,  Pclass/type  has  Multi-value) 

(6)  An  attribute  can  be  specified  as  MANDATORY,  which 
means  that  a  null  value  is  not  allowed  for  it. (e.g., 
Iclass ) 

(7)  An  attribute  can  be  specified  as  not  changeable,  which 
means  that  once  set  to  a  nonnull  value,  this  value 
cannot  be  altered  except  to  correct  an  error,  (e.g., 
Iclass) 

(8)  A  member  attribute  can  be  required  to  be  EXHAUSTIVE  of 
its  value  class.  This  means  that  every  member  of  the 
value  class  of  the  attribute  must  be  the  value  of  some 
entity. 

(9)  A  multivalued  member  attribute  can  be  specified  as 
NONOVERLAPPING,  which  means  that  the  values  of  the 
attribute  for  two  different  entities  have  no  entities 
in  common. 

1.  Member  Attribute  Iniecrglgtipaskips 
a.  Inversion 

The  first  way  in  which  a  pair  of  member 
attributes  can  be  related  is  by  means  of  INVEFSION.  wemter 


D.  ATTRIBUTE 

In  Figure  4.6  above,  each  class  has  an  associated 
collection  of  attributes.  Fach  attribute  has  the  following 
features . 

(1)  An  attribute  name  identifies  the  attribute.  An 

attribute  must  be  unique  with  respect  to  the  set  of 
all  attribute  names  used  in  the  class,  the  class's 
underlying  base  class,  and  all  eventual  subclass  of 
that  the  base  class  (e.g.,  Iclass,  lid''  in  IPFC 
(Figure  4.2). 

(2)  The  attribute  has  a  value  which  is  either  an  entity  in 

the  database  or  a  collection  of  such  entities.  The 
value  of  an  attribute  is  selected  from  its  underlying 
value  class,  which  contains  the  permissible  values  of 
the  attribute.  The  value  of  an  attribute  may  also  be 
the  special  value  NULL .  (e.g.,  INS-CLASS,  INS-ID)  in 

IREC  (Figure  4.2) . 

(3)  The  APPLICABILITY  of  the  attribute  is  specified  by 
indicating  that  the  attribute  is  either: 

(a)  a  member  attribute,  which  applies  to  each 
member  of  the  class,  and  so  has  a  value  for 
each  member  (e.g.,  Iclass  of  IFFC  )  (Figure 
4.2) 

(b)  a  class  attribute,  which  applies  to  a  class 
as  a  whole,  and  has  only  one  value  for  the 
class  (e.g.,Idate  of  IREC) 


WEAPON-CLASS  :  subclass  of  STRINGS  where  value  is 


AC,  SH,  ABU 

WEAPON-TYPE  :  subclass  of  SRTIN  S  where  value 
is  positive  single  digit  integer  1,2, 2, 4, 5,6 
RANGE  :  subclass  of  STRINGS  where  value  is 
positive  integer  less  than  100,000 
FUEL-CAPACITY  :  subclass  of  STRINGS  where  value 

is  positive  integer  less  than  20,000 
MAX-LOAD  :  subclass  of  STRINGS  where  value  is 
positive  integer  less  than  500,000 
DATE  :  Subclass  of  STRINGS  where  value  is 
positive  integer  between  1...365 
INS-CLASS  :  subclass  of  STRINGS  where  format 
is  2  characters:  AF,  PO,  AR 
INS-ID  :  format  is  3  digit  positive  integer 
AREA  :  value  is  in  between  1...100 
N0-OF-PERSON  j  value  is  less  than  10,000 
FR IEND-OR-FOE  :  formats  are  FRD,  FOE 
NUM-OF-WEAPON  :  format  is  positive  integer 
WEATHER  :  value  is  FAIR,  CLDY  or  PCLDY 
AMMO-CAT  :  value  is  single  letter 
RRANGE  :  value  is  positive  integer 
WARHEAD  :  value  is  positive  integer  1...10 

Figure  4.6  Domain  of  Attribute 
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description  :  all  information  related  to 
weapon  class/type  and  their  physical 
characteristics  . 

Member  attribute  : 

Wclass 

Value  class  :  WEAPON-CLASS 
Mandatory 

Vtype 

description  :  Weapon  Type 
Value  class  :  WEAPON-TYPE 
Mandatory 

Wf  f 

description  :  whether  the  weapon 
is  Friend  or  Foe 
Value  class  :  WREC 

Wammo 

description  :  What  sort  of  Ammo 

can  be  available  for  particular 
type  of  weapons 
Value  class  :  AREC 
Inverse  :  Vclass/Type-Needed 
Multivalued 

Wrange 

description  :  Weapon  range 
Value  class  :  RANGE 

Wf  uel 

description  :  Fuel  capacity 

of  weapon 

Value  class  :  FUEL-CAP 

W1  bs 

description  :  Maximum  Load 
Value  class  :  MAX-LOAD 
not  changeable 

identifier  :  Wclass  +  Wtype 


AREC 


description  :  Ammo  categories  and  their 

physical  characterics 
Member  attribute  : 

Acat 

description  :  Ammo  category 
Value  class  :  AMMO-CATEGORY 
Manda  t  ory 
Not  changeable 

Where-needed 

description  :  What  kind  of 

Weapon  class/type  needed 
for  this  Ammo  category 

Albs 

description  :  Weight  of  1  round  of 
Ammo 

Value  class  :  MAX-load 

Mandatory 

Not  changeable 

Akill 


description 


Killing  radius 
of  Ammo 


Value  class  :  RANGE 


Avar 


descript  1  on 


Type  of  warhead 
of  Ammo 


Value  class 


WARHEAD-CAT 


Identifier  :  Acat 


Figure  4.4  SDM  of  AREC  in  the  Intelligence  Database 
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PREC 


description  :  information  about  the 

reconnaissance  date,  weapons  observed  and 
weather  condition 
Member  attributes  : 

Pday 

description  :  the  day  of  the  year 
on  which  the  photo  taken 
Value  class  :  DATE 

Pid 

description  :  Installation  Id  code 
Value  class  :  INS-ID 
Manda  tory 

Pcla  ss/type 

dscription  :  Concatenation  of 
weapon  class  and  type 
Value  class  :  Weapon-class  / 
weapon-type 

Multivalued 

Pnum 

description  :  observed  weapons 
Value  class  :  NUM-OF-WEF 

Pwc 

description  :  Weather  condition 
Value  class  :  WEATHER 
Manda  tory 

Idenfitier  :  Pday  +  Pid  +  Pclass/type 


INSTALLATION 


description  :  the  basic  master  file  for 
installation  representing  all  informations 


about 

Class, 


installation  such  as  Installation 
Id  code.  Area  and  their  physical 


and  tactical  characteristics. 

member-attribute  : 

I  class 

Description  :  Installation  class 
Value  class  :  INS-CLASS 
Mandatory 
Not  changeable 

lid 

Description  :  Installation 

Iden  tif ica  ti on 
Value  class  :  INS-ID 
Mandatory 
Not  changeable 

Iarea 


Description 
Value  class 

Iper  s 

description 
Value  class 

Iff 


Estimated  Area 
AREA 

Estimated  persons 
NO-OF-PERSONS 


Ida 


Value  class 
ss/I type 
description 


:  FFIEND-OF-FOE 
:  Concatenation  of 


weapon  class  and  type 
Value  class  :  PREC 

Match  :  PCLASS/PTYPE  of  PREC  on  PID 
'Cond2':  Multivalued 

Not  changeable 


Class  attribute  : 

Total-foe 

description  :  total  foe  numbers 
Value  class  :  TCTAl-NUMFEF 


Identifier  :  lid 


0.  SDH  ?OR  INTXLLIOSNCI  DATABASE 


Figure  4.2,  Figure  4.3,  Figure  4.4,  Figure  4.5  show  a 
SDM  logical  schema  for  the  Intelligence  Datsabase.  The  data 
given  in  Appendix  A  to  be  used  is  composed  of  four  records; 
First*  Installation  records  which  describe  the  normal  Master 
file  of  Installation  Includes  several  fields  such  as  Iclass, 
lid,  Iarea,  Ipers,  Iff,  I  class/I  type .  Second,  Ammunition 
records  which  describe  all  information  about  Ammunition 
include  several  fields  such  as  Acat,  Albs,  Akill,  Avar. 
Third,  Photo  records  which  describe  all  information  of  Photo 
taken  includes  several  fields  such  as  Pday,  Pii, 
Pclass/Ptype,  Pnum,  Pwc.  Finally  Weapon  records  which  have 

all  information  of  Weapons  include  fields  such  as  Welass, 
Wtype,  Wff,  Wammo,  Wrange,  Wfeul,  Wlbs.  INSTALLATION  is 
first  defined.  The  class  Is  named,  and  then  an  informal 
description  of  the  class  Is  provided.  The  description,  which 
is  optional,  defines  the  purpose  and  content  of  the  class. 
Special  remarks  are  written  here.  Next,  the  member- 
attributes  are  defined.  These  are  attributes  of  the  entities 
in  this  class.  According  to  the  Photo  days  in  Photo  record, 
Installation  records  are  updated,  so  Iclass/Itype  has  ’“'at  eh 
function;  Match  :  PCLASS/PTYPE  of  FREC  on  PIT.  And 


Ammunition  and  Weapon  records  are  a ut oma t ice  1 1 y  updated. 


(5)  There  are  several  primitive  ways  of  finding  interclass 
connections  and  derived  attributes,  corresponding  tc 
the  most  common  types  of  information  redundancy 
appearing  in  database  applications.  These  facilities 
integrate  multiple  ways  of  viewing  the  same  basic 
information . 

1 .  Basic  Format  of  an  SEM  Entity  Cla^s 

The  basic  format  of  an  SEP  entity  class 
description  is  given  in  Figure  4.1.  [Ref.  3] 


ENTITY-CLASS-NAME 

[description - ] 

[interclass  connection  - ] 

member  attribute  : 

At  tr ibute-name 

value  class  :  - 

[mandatory] 

[multivalued]  [no  overlap  in  values] 
[exhaust  value  class]  [not  changeable] 
[inverse  :  Attribute-name] 

[match  :  Attribute-name 

ENTITY  -  CLASS  on  At t ri bu t e-aame2] 


!  [derivation  :  - ] 

I 

I 

i  [  class  attribute  : 

I 

I 

j  Attribute-name 

,  [description  : - ] 

!  value  class  :  - 

j  [derivation  :  - ]] 

I 


identifier  :  attribute-name  +  [At t r i but e-name2  +  [  ]]] 


V.  RELATIONAL  DATABASE  DESIGN 


A.  INTRODUCTION 

The  relational  model  was  first  proposed  by  Dr.  E.  ?. 
Ccdd  in  a  seminal  paper  in  1S70  [Ref.  13].  This  innovation 
stressed  the  independence  of  the  relational  representation 
from  physical  computer  implementation  such  as  ordering  on 
physical  devices,  indexing,  and  using  physical  access  paths. 
The  model  thus  formalized  the  separation  of  the  user  view  of 
data  from  its  eventual  implementation;  it  was  the  first 
model  to  do  so.  In  addition,  Codd  proposed  criteria  for 
logically  structuring  relational  databases  and  an 
implementation-independent  language  to  operate  on  these 
databases.  The  relational  model  represents  data  in  the 
simple  form  of  tables.  The  relational  model  is  attractive 
in  database  design  because  it  provides  formal  criteria  for 
logical  structure,  namely,  normal  form  relations. 

1 •  Terminology 

A.  relation  is  simply  a  two-dimensional  table  that 
has  several  properties.  First,  the  entries  in  the  table  are 
single-valued;  neither  repeating  groups  nor  arrays  ere 
allowed.  Relations  are  flat  files.  Columns  of  a  relation  are 
refered  to  as  attributes.  Each  row  of  the  relation  is  known 
as  a  tuple.  If  the  relation  has  n  columns,  then  each  row  is 


54 


1  ilHPM  »  m  p  u  ■  ■■  i  i 

refered  to  as  an  n-tuple.  Also,  a  relation  that  has  n 
columns  or  n  attributes  is  said  to  he  of  degree  n. 

2.  I§X!  of  Relation 

This  key  is  the  attribute  or  set  of  attributes 
that  uniquely  identifies  tuples  in  a  relation.  A  relation 
key  is  formally  defined  as  a  set  of  one  or  more  relation 
attributes  concatenated  so  that  the  following  three 
properties  hold  for  all  time  end  for  any  instance  of  the 
rele  ti on : 

1.  Uniqueness  :  The  set  cf  attributes  takes  on  a  unique 
value  in  the  relation  for  each  tuple. 

2.  Nonredund ency  :  If  an  attribute  is  removed  from  the 
set  of  attributes,  the  remaining  attributes  do  not 
posses  the  uniqueness  property. 

3.  Validity  :  N'o  attribute  value  in  the  key  may  be  null. 

When  two  or  more  attributes  or  attribute 
collections  can  be  keys,  they  are  called  candidate  keys. 
When  one  of  the  candidates  is  selected  to  be  the  key,  it  is 
called  the  primary  key.  When  an  attribute  in  one  relation 
is  a  key  of  another  relation,  the  attribute  is  called  a 
foreign  key.  Foreign  keys  are  important  when  defining 
constraints  across  relations. 

3.  Relational  Algebra 


The  relational  algebra  consists  of  a  set  of 
relational  algebra  operators.  Each  operator  has  one  or  more 
relations  as  its  input  and  produces  a  relation  as  its 


output.  The  three  basic  relational  algebra  operations  are 
SELECTION,  PROJECTION,  and  JOINING. 

The  SELECTION  operator  selects  all  tuples  from 
some  relation  such  that  some  attributes  in  each  tuple 
satisfies  some  condition.  A  new  relation,  which  contains  the 
selected  tuples,  is  then  created. 

The  PROJECTION  operator  constructs  a  new  relation 
from  sore  existing  relation  by  selecting  only  attributes  of 
the  existing  relation  and  eliminating  duplicate  tuples  in 
the  newl^  formed  relation. 

The  JOINING  is  a  method  of  combining  two  or  more 
relations  into  a  single  relation.  At  the  outset  it  requires 
the  choice  of  attributes  to  match  tuples  in  the  relations. 
Tuples  in  different  relations,  but  with  the  same  value  of 
matching  attributes,  are  combined  into  a  single  tuple  in  the 
output  relation.  The  examples  of  using  three  basic 
operators  will  be  shown  in  Chapter  IV. 

B.  RELATIONAL  NORMAL  FORMS 

Not  all  relational  database  designs  are  equal?  some  are 
better  than  others.  Obviously,  a  design  that  meets  the 
users'needs  is  better  than  one  that  does  not,  but  there  are 
other  criteria  as  well.  With  some  relations,  changing  data 
can  have  unexpected  consequences.  These  consequences,  called 
modification  anomalies,  are  undesirable.  These  anomalies  can 
be  eliminated  by  changing  the  database  design.  Usually 
relations  without  modification  anomalies  are  pref ered  .  Some 


relations  are  independent,  others  are  interdependent. 
Generally,  hut  not  always,  the  less  interdependency,  the 
better . 

1  •  An ornaligs 

Consider  Ammunition  relation  in  Figure  5.1.  It 
has  the  attributes  ACAT,  ALE?,  AKILL,  and  AWAR .  The  meaning 
of  a  tuple  is  that  given  an  Ammo  category.  Weight  of  Cne 
round  and  Killing  Radius  and  Warhead  Category  are 
determined . 

For  the  data  in  Figure  5.1,  if  we  delete  the 
tuple  for  ACAT  A,  we  will  lose  not  only  the  fact  that  Ammo 
Category  A's  Weight  is  410  lbs,  but  also  the  fact  that 
Killing  radius  is  100  feet.  This  is  called  a  DELETION 
ANOMALY!  we  may  be  losing  more  information  than  desired.  We 
lose  facts  about  three  attributes  with  one  deletion.  This 
characteristic  may  be  considered  undesirable  because  it  is 
usually  unintended. 
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Also,  suppose  we  want  to  enter  the  fact  that  ACAT 
E  has  a  killing  radius  of  525  feet.  We  can  not  enter  this 
|  data  into  the  Ammunition  relation  until  a  ACAT  has  ALBS  and 

AW AH.  This  restriction  seems  unnecessary.  This  situation  is 
called  an  Insertion  Anomaly.  We  gain  facts  atout  three 
I  attributes  with  one  insertion?  or,  stated  negatively,  we 

cannot  insert  a  fact  about  one  attribute  until  we  have  ar. 
additional  fact  about  another  attribute.  These  anomalies 

I 

I  can  be  eliminated  by  the  creating  two  new  relations  via 

projection.  An  example  of  this  will  be  shown  in  Figure  5.9. 

2.  Classes  of  Mod  1  f i £§£1  on  £no[nalie§ 

There  are  many  different  types  of  modification 
anomalies.  In  the  1970s  relational  theorists  chipped  away  at 
j  these  types.  Someone  would  find  an  anomaly,  classify  it,  and 

think  of  a  way  to  prevent  it.  This  process  generated 
improved  criteria  for  designing  relations.  These  criteria 
j  are  called  Normal  Forms. 

Codd,  in  his  paper  [Ref.  13]  defined  first, 
second,  and  third  normal  forms.  Later,  Boyce-Codd  normal 
form  was  postulated,  and  then  fourth  and  fifth  normal  forms 
were  defined.  As  seen  in  Figure  5.2,  each  of  these 


normal  forms  contains  the  other.  A  relation  in  fifth  normal 
form  is  aut oma t ioal ly  in  1,  2,  3,  BC,  and  4  normal  forms. 


I - IMF 

- ?K? 

- 3  NF 

- FCNF 

- 4N7 

- 5N; 

!  *  EK/NF 


Figure  5.2  Relationship  of  Normal  Forms 

These  normal  forms  were  helpful,  hut  they  had  a 
serious  limitations.  No  theorist  was  able  to  guarantee  that 
any  of  these  forms  would  eliminate  all  anomalies;  each  form 
would  eliminate  just  certain  anomalies.  This  situation 
changed,  however,  in  1981  when  R.Fagin  defined  a  new  normal 
form  called  DOMAIN/KEY  normal  form(D K/NF).  Fagin  showed  that 
a  relation  in  comain/key  normal  form  is  free  of  all 
modification  anomalies,  regardless  of  their  types. 

Until  EK/NF  was  identified,  it  was  necessary  for 
relational  database  designers  to  continue  looking  for 
more  and  nore  anomalies,  and  more  and  more  normal  forms. 
Fagin's  proof,  however,  greatly  simplified  the  situation. 
If  we  can  put  a  relation  in  EK/NF,  then  we  are  guaranteed  it 
will  have  no  anomalies. 

3.  Kinds  of  Normal  Forms. 


All  relations  are  in  first  normal  form.  A  relation 
is  in  first  normal  form  if  and  only  if  all  underlying 


domains  contain  atomaic  values  only.  Relations  in  first 
normal  form  have  modification  anomalies.  It  is  possible  to 
eliminate  some  of  these  anomalies  by  putting  the  relation  in 
second  normal  form.  We  can  eliminate  even  mor"  rfhen  the 
relation  is  put  in  third  normal  form,  and  even  more  with 
Boyce-Codd  normal  form. 

A  functional  dependency  (?D)  [Ref.  6]  is  a  term 
derived  from  mathematical  theory?  it  concerns  the  dependency 
of  values  of  one  attribute  or  set  of  attributes  on  those  of 
another  attribute  or  set  of  attributes.  Formally,  a  set  cf 
attributes  X  is  functionally  dependent  on  a  set  of 
attributes  T  if  a  given  set  of  values  for  each  attribute  in 
T  determines  a  unique  value  for  the  set  of  attributes  in  X. 
The  notation  T  — >  X  is  often  used  to  denote  that  X  is 
functionally  dependent  on  7.  The  att  ibutes  in  Y  are  known 
as  the  determinant  of  the  functional  dependency  Y  — >  X. 

A  relation  is  in  second  normal  form  if  and  only  if 
it  is  in  INF  and  every  nonkey  attribute  is  fully  dependent 
on  the  primary  key. 

A  relation  is  third  normal  form  if  it  has  the 
following  properties:  (1)  The  relation  is  in  second  normal 
form.  (2)  Evpry  nonkey  attribute  is  nontransitively 
dependent  on  the  primary  key. 

A  relation  is  in  BCNF  if  every  determinant  is  a 
candidate  key.  Since  relations  in  BCNF  have  no  anomalies 
regarding  functional  dependenies,  this  seemed  to  put  the 


issue  of  modification  anomalies  to  rest.  However,  it  was 
soon  discovered  that  anomalies  can  arise  from  situations 
other  than  functional  dependencies. 

Formally,  multivalued  dependency  is  defined  as 
follows;  In  relation  P.(X,Y,Z),  X  ==>  Y  if  each  X  value  is 
associated  with  a  set  of  Y  values  in  a  way  that  does  not 
depend  on  the  Z  values. 

A  relation  is  in  : ourth  normal  form  [Hef.  6]  if  it 
is  in  BCNF  and  has  no  multivalued  dependencies .  This 
definition  means  that  if  a  relation  has  multivalued 
dependencies  and  is  in  fourth  normal  form,  then  the 
multivalued  dependencies  have  a  single  value.  In  other 
words,  all  independent  attributes  have  a  single  value. 

A  relation  is  in  fifth  normal  form  if  and  only  if 
every  join  dependency  in  a  relation  Is  implied  by  the 
candidate  keys  of  the  relation. 

A  relation  is  in  EX/N?  if  every  constraint  on  the 
relation  is  a  logical  consequence  of  the  definition  of  keys 
and  domains.  A  constraint  is  any  rule  on  static  values  of 
attributes  that  is  precise  enough  that  we  can  evaluate 
whether  or  not  it  is  true.  Thus  intra-  ana  inter-relation 
constraints,  functional  dependencies,  multivalued 
dependencies,  and  Join  dependencies  are  all  examples  of 
constraints.  BK/NF  means  that  if  we  can  find  a  way  to 
define  keys  and  domains  such  that  all  constraints  will  be 
satisfied  when  the  key  and  domain  definitions  are  satisfied. 


then  modification  anomalies  are  impossible.  Unfortunately, 
there  is  no  known  way  to  convert  a  relation  to  BK/NF 
automatically,  nor  is  it  even  known  which  relations  can  he 
converted  to  BZ/NF.  In  spite  of  this,  BZ/NF  can  he 
exceedingly  useful  for  practical  database  design. 

C.  RELATIONAL  DATABASE  DESIGN  CRITERIA 

Berri  and  co-workers  [Ref.  9]  have  identified  three 
relational  criteria: 

(1)  Representation  :  The  final  structure  must  correctly 
represent  the  original  specification. 

(2)  Separation  :  The  original  specifications  are  divided 
into  relations  that  satisfy  certain  conditions. 

(?)  Redundancy  :  The  final  structure  must  not  contain 

any  redundant  information. 

First  of  all,  the  database  must  be  separated  into  a 
number  of  normal  form  relations.  The  other  two  criteria  are 
relatively  general.  In  spelfic  terms  each  can  be  applied  to 
attributes,  functional  dependencies  or  data.  To  determine 
the  criteria  more  specifically,  notation  for  a  relation  and 
the  input  and  output  of  a  design  process  is  needed. 

A  relation  is  defined  as  made  up  of  two  components,  the 
attribute  and  the  functional  d ependenci ps ( FB )  between  the 
attributes.  The  definition  takes  the  form 

K  =  (  {A , B , C }  ,  (A  ==>B ,  A  ==>  C}) 

Here  R  comprises  three  attributes,  A,  B,  and  C.  The  FBs 
between  these  attributes  are  A  ==>  E  and  A  ==>  C.  The 


notation  used  to  describe  the  input  and  output  of  the  design 
process  is  Sin  and  Sout.  Both  Sin  and  Sout  is  are  sets  of 
relations.  Here  Sin  is  the  input  to  the  design  process  anc 
Sout  is  the  output.  Most  theoretical  worse  is  tasec  on  the 
universal  relation  assumption  and  assume  that  Sin  is  one 
relation,  the  universal  relation,  which  is  defined  cy  a  set 
of  attributes  and  FDs,  using  the  preceding  notation,  and 
that  Sout  is  a  set  of  normal  relations,  each  of  which  is 
made  up  of  a  set  of  attributes  and  a  set  of  FDs. 

1 •  Satisfying  Representation  Criteria 

One  goal  of  any  design  process  is  to  produce  an 
output  design,  Sout,  to  accurately  represent  Sin.  Further, 
all  the  relations  in  Sout  must  satisfy  the  conditions  for 
normal  form.  C.Berri  and  co-wor £ers ( 1979  )  [Ref.  9]  have 
defined  three  representation  criteria  for  the  representation 
of  Sin  by  Sout  : 

*  REP1  :  The  relation  Sout  contains  the  same 

attributes  as  Sin. 

*  REP2  :  The  relation  Sout  contains  the  sarnie  attributes 
and  the  same  FDs  as  Sin. 

*  REP3  :  The  relations  in  Sout  contain  the  samp 

attributes  and  the  same  data  as  Sin. 

RFP1  is  trivial.  It  requires  all  the  attributes  ir. 


Sin  to  also  apppear  in  the  relations  in  Sout.  rut  it  does 
not  consider  any  dependencies  between  tbe  attributes. 


In  regard  tc  REP2,  recall  that  Sin  is  defined  as  a 
set  of  attributes  and  FEs  and  that  each  relation  in  Sout 
will  also  contain  a  set  of  attributes  and  a  set  of  FEs. 
Fepresentation  FEP2  requires  that  each  FD  in  Sin  be  either 

*  contained  as  an  FD  in  one  of  the  relations  in  Sout  or 

*  derived  from  the  FDs  in  the  relations  in  Sout.,  using 
the  FD  inference  rules. 

For  example,  in  Figure  5.3,  Sin  =  ({A,3,C},  {A 
==>  B,  C  ==>  ?}),  Sout  =  (P2,F3)  where  F2  =  ({A,?},  {A  ==> 
B>)  and  F.3  =  ({B,C},  {C  ==>  B}).  Thus  R2  and  F3  constitute 
the  decomposition  by  projection  of  Sin. 
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Decomposition 


2 .  Lossless  DecfiniE2ii.ti.0SS 

Formally,  a  lossless  decomposition  can  be 
described  as  follows.  The  decomposition  of  a  relation 
F.(X,Y,Z)  into  F.l  and  F.2  is  defined  by  two  projections: 

*  R1  =  projection  of  R  over  X,7 

*  R2  =  projection  of  R  over  X,Z 

where  X  is  the  set  of  common  attributes  in  HI  and  R2.  The 
decomposition  is  lossless  if  R  =  join  of  Rl,  R2  over  X.  The 
composition  is  lossy  if  R  C  join  of  R1,R2  ever  X. 

3 •  Redundancy  Cri tera 

Redundancy  criteria  can  be  defined  in  various 
ways.  One  way  of  defining  redundancy  criteria  is  as  fellows: 

*  RED1  :  A  relation  in  Sout  is  redundant  if  its 
attributes  are  contained  in  the  other  relations  in  Sout. 

*  RED2  :  A  relation  in  Sout  is  redundant  if  its  FDs  are 
the  same  or  can  be  derived  from  the  FDs  in  the  other 
relations  in  Sout. 

*  RED?  :  A  relation  in  Sout  is  redundant  if  its  content 
can  be  derived  from  the  contents  of  other  relations  in 
S  out . 

Obviously,  REE1  is  not  a  very  useful  criterion, 
because  during  separation  it  is  often  necessary  to  create 
separate  relations  that  represent  FDs  between  attributes, 
which  may  appear  in  other  relations.  On  the  other  hand,  RED? 
and  RED?  can  be  quite  useful  criteria.  Any  design 
algorithms  should  in  particular  avoid  RED3,  bpcausp  it 


would  keep  the  same  data  in  more  than  one  relation.  Such 
relations  could  all  he  in  normal  form  and  no  anomalies  would 


occur  in  relations.  However,  interrela ti  onal  a  omalies  would 
arise  if  some  fact  were  updated  in  one  relation  tut  the 
other.  Designs  that  include  RFD2  would  cause  the  same 
pro  tlen . 

4.  El imina ti on  pf  Modification  Anomaligg 

If  relations  can  be  put  into  EK/NF,  then  no 
modification  anomalies  can  occur.  Thus  EK/MF  becomes  a 
design  objective,  and  relations  that  are  in  DY./KF  are 
usually  preferred. 

Not  all  relations,  however,  can  be  put  into  EK/NF. 
This  occurs  when  there  are  constraints  that  cannot  be 
expressed  as  logical  consequences  of  keys  and  domains.  As 
example  described  by  Fagin  [Ref.  14]  is  a  relation  having 
the  following  constraints:  The  relation  must  never  have 
fewer  than  three  tuples.  There  is  no  way  to  express  this 
constraint  in  terms  of  domains  and  keys.  Thus  it  has  a 
modification  anomaly.  In  fact,  this  strange  relation  has  a 
deletion  anomaly  but  no  insertion  anomaly. 

When  relations  cannot  be  tranformed  into  E.K/NF, 
the  const raint  that  cannot  be  expressed  in  terms  of  domains 
and  keys  must  be  inserted  into  application  programs.  This  is 
undesirable  because  the  constraint  is  hidden. 
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Ease  of  Use 

A  fifth  criterion  for  a  relational  design  is  ease 


of  use.  As  far  as  possible,  we  strive  to  structure  the 
relations  so  that  they  are  familiar  and  seem  natural  to 
users.  Sometimes  this  goal  conflicts  with  the  elimination  of 
anomalies  or  with  i ndependenoe  . 

D.  RELATIONAL  DATABASE  MANAGEMENT  SYSTEM 

This  section  [Ref.  3]  describes  the  relational  model  as 
the  implementation  model  that  is  supported  by  a  EPMS  .  Any 
relations  produced  during  data  analysis  can  be  implemented 
directly  on  this  DBMS.  Because  of  its  tabular  interface, 
the  relational  model  makes  an  attractive  implememt a i on 
model.  It  is  receptive  to  two  types  of  environments: 

*  the  traditional  data  processing  environment,  in  which 
databases  are  set  up  by  professional  computer 
programmers  on  behalf  of  database  users. 

*  environments  in  which  nonprogrammer  users  set  up  .their 
own  databases. 

The  relational  model  provides  the  same  advantages  in 
both  types  of  environments.  Its  natural  interface  simplifies 
the  design  and  use  of  the  database.  This  is  particularly  so 
if  a  language  with  powerful  selective  capabilities  can  be 
provided  by  the  EB^S.  Such  languages  can  reduce  program 
development  time  and  hence  are  attractive  in  commercial 
data-pr ocess ing  environments.  They  are  also  attractive  to 
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VI.  IMPLItJENlAXIQN  QgXijS  QgACLE 


The  Intelligence  database  has  been  implemented  using 
the  ORACLE  relational  DEMS.  Initially  a  data  file  is  created 
using  CRFATE  command.  After  the  creation  of  the  IREC  file, 
it  appears  as  shown  below. 


ufi>  c« e * f e  t »hle  i*ec 

2  (  1  Ci-ASS  Ch4»<2). 

5  no  nij«8£R ( r» , 

a  [43t4  Nu^RER  ( 2 1  . 


5 

a 


IP;RS  mii^HER  {4|, 
if*  CH4»n>it 


Taol«  creatsd. 


After  the  table  is  created,  IREC  data  is  added  to  the 
data  file  using  the  INSERT  command. 


'jp- 1  >  insert  into  isec  viljEs  ('»£',  i  o  i  ,  a,  isoo,  •  coe  ' )  ; 

1  r,c  3M  C  r-rit  >*  T  . 

UCI>  INSERT  INTO  [RFC  V4LJF.5  (  *  4?  *  .  1  l  0  ,  1  0  .  MOO  ,  •  FOE  '  )  I 
I  r*c  3  r-j 


After  IREC  file  is  created,  list  all  the  data  in  the 
IREC  using  SELECT,  FROM  command. 

UFt>  select  . 

2  'ROM  ire:; 
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areas  as  concurrency,  locking,  security,  integrity,  view 
definition,  etc,  has  taken  the  relational  approach  as  a 
starting  point,  precisely  because  it  provides  a  clean 
conceptual  base.  As  for  the  question  of  an  undering  theory, 
the  realtional  approach  is  not  only  soundly  based  on  certain 
aspects  of  mathematical  set  theory,  but  it  also  possesses  a 
considerable  body  of  theory  in  its  own  right  aimed 
specifically  at  its  application  to  database  problems. 

In  a  relational  schema  the  entire  information  content 
of  the  database  is  represented  by  means  of  a  single  data 
construct,  namely,  the  n-ary  relation.  In  a  network  schema, 
by  contrast,  there  exits  at  least  one  fanset  bearing 
information  essentially*  for  it  there  did  not,  the  schema 
would  degenarate  into  a  relational  schema  with  certain 
eipllcit  access  paths.  In  other  words,  there  are  at  least 
two  essential  data  constructs  in  the  network  approach,  the 
baseset  and  fanset.  In  DBTG,  in  particular,  there  are  five 
data  constructs,  any  or  all  of  which  may  be  used  to  describe 
essential  information: 

*  record  type  (corresponds  to  baseset); 

*  DETG  set  (corresponds  to  fanset); 

*  singular  set; 

*  ordering; 

*  repeating  group. 
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fi*  A  COMPARISON  VITB  THE  NETWORK  APPROACHES 

Successful  DBTG  systems  lack  the  flexibility  of 
relational  systems,  hut  they  make  up  for  it  in  being  able  to 
process  larger  amounts  of  data  more  quickly.  Systems  like 
this  excel  at  standardized,  repetitive  applications  such  as 
online  teller  processing,  or  large-scale  order  entry,  and 
the  like.  They  may  not  be  elegent,  hut  they  can  do  large 
amounts  of  work,  and  do  it  well. 

Thus,  we  have  the  following  situation:  relational 
systems  are  easy  to  use,  applications  can  he  quickly 
developed,  hut  processing  of  very  large  amounts  of  data  can 
be  unacceptably  slow.  On  the  other  hand,  TBTG  is  more 
difficult  to  use,  hut  large  amounts  of  work  can  he  quickly 
and  efficiently  accomplished.  The  LETS  representation  of 
the  Intelligence  Database  is  given  in  Appendix  E. 

These  observations  were  true  in  1983,  hut  development 
efforts  are  underway  in  both  camps  to  eliminate  the 
shortcomings.  Vendors  of  relational  systems  are  striving  to 
improve  performance,  whereas  vendors  of  nonrelational 
systems  are  attempting  to  make  their  systems  easier  to  use. 
One  way  they  are  doing  this  is  to  give  the  nonrelational 
systems  a  relational  appearance  to  the  user. 

In  the  relational  approach,  all  information  in  the 
database  is  represented  using  one  construct,  and  moreover 
this  one  construct  is  both  simple  and  familiar.  It  is 
significant  that  most  of  the  research  since  1970  into  such 


4 •  Attribute  Dsmains 

Each  attribute  has  its  own  domain.  The  value  of 
each  attribute  must  be  within  its  domain.  The  domain  of 
each  attribute  is  shown  in  Figure  5.9. 
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Figure  5.9  Attribute  Domains 
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3.  Eslitiaas  2 1  lai£lli&£&££  sg.jie.rna 

After  these  four  records  are  examined,  Inverse  and 
Match  functions  must  be  deleted  in  order  to  achieve  DK/NF. 
We  have  repeating  groups,  because  IREC  and  WREC  have 
multiple  values.  Repeating  groups,  however,  are  prohibited 


in  relational  databases,  so  two  inte  relation  constraints, 
AW  and  IETEMP,  were  added.  The  AW  record  is  composed  of 
WCLA5S,  WTYPE ,  and  ACAT;  and  IETEMP  is  composed  of  IID, 
I  CLASS ,  and  ITYPE . 

Because  of  interrelation  constraints.  Weapon  class 
and  Weapon  Type  are  omitted  from  IREC,  and  Wammo  is  omitted 
from  WRFC.  All  attributes  are  dependent  on  the  primary  key, 
so  there  are  no  modification  anomalies.  The  relations  in  the 


INTELLIGENCE  Schema  is  given  in  Figure  5.9. 


2.  S^siem  II owcfca^i  §54  Bfiiaii2a5illl5 

The  system  flowchart  and  relationships  between  the 
various  master  files  are  shown  in  Figure  5.3.  It  shows  how 
all  four  master  files  can  he  updated  automatically  ty 
utilizing  the  Photo  master  files-  The  use  of  simple  query 
language  will  produce  a  large  volume  of  new  data  easily  and 
quickly.  Three  SDM  facilities  will  he  used  to  explain  how 
it  works. 

Initially,  the  four  maste  files  are  created. 
Installation  records  are  sorted  according  to  the  IID,  and 
Photo  records  are  sorted  accordin  to  the  PID.  The 
derivation  facility  will  yield  the  Total-f oe-nnmber  from 
the  Installation  file  and  the  Observed-weapon-add  from  the 
Photo  file.  The  inverse  facility  on  the  two  master  files 
yields  the  new  master  file  called  Installation  and  Photo 
file  which  Includes  PNUM  and  PWC.  The  derivation  facility 
will  produce  the  new-weapon  list  from  the  Installation  and 
Photo  file  by  comparing  PDA!  with  previous  PEAT.  The  inverse 
facility  on  this  new  master  file  and  the  Weapo  master  file 
will  yield  the  new  master  file  called  Installation  and  Phcto 
and  Weapon  by  comparing  VC LASS  and  WTYPE  with  ICLASS  and 
ITYPE  giving  us  new  information  such  as  WAPMC,  WRANGE, 
VFEUL .  The  final  use  of  IREC,  PP.EC,  WF.EC,  APEC  files, 
necessitated  by  repeating  WAMMO  groups,  yields  the  new 
master  file  called  Installation,  Photo,  Weapon,  and 
Ammunition  giving  us  the  new  information  such  as  ALBS,  AVAR. 


implemented,  because  security  authorizations  will  relate  to 
relations. 

D.  CONVERSION  01  SDM  INTO  RELATION  DATABASE  DESIGN 
1.  Relationship  Between  Records 

The  relationships  for  the  Intelligence  Database 
are  given  in  Figure  5.7.  Inversion,  Matching  and  Derivation 
will  be  used  to  provide  inter-relationships  between  the 
attributes  shown.  It  is  possible  to  find  duplicated  field 
names  using  these  methods. 


INSTALLATION  RECORDS 


ICI.ASS  I  ID  I  AREA  APERS  IFF  ICLASS/ITYPE 
— 


ACAT 


Inverse 


AMMUNITION  RECORD 


Match 


ALBS 


akill 


A  WAR 


_  i  _ _ _ _ _ _ _ _ _ _ _ _ 


PHOTO  RECORDS 


PEAT  PID  PCLASS/PTYPE  PNUM  PWC 


WEAPON  RECORDS 


WCLAS  WTYPE  WFF  WAMMO  WRANGE  WFUEL  WLBS 


Figure  5.7  The  Rel a t i onsh ins  between  Records 


the  JOIN  operation  is  likely  to  take  substantial  machine 
time.  It  may  be  feasible  with  small  relations,  tut  some 
commercial  files  are  hundreds  of  million  of  bytes  long.  In 
understanding  the  performance  issue,  it  is  very  important  to 
remember  that  the  relations  and  the  operations  on  them  such 
as  the  JOIN  will  never  take  place  physically.  Instead, 
equivalent  results  will  be  produced  by  means  of  pointer 
structures  or  indices. 

A  relational  database  design  is  sometimes  depicted 
as  not  being  'driven'  by  a  user  view  of  the  data.  A  new 
unanticipated  user  view  can  be  handled  with  ease  if  the  data 
it  needs  are  stored.  Although  this  is  true  in  connection 
with  the  logical  structure  of  the  data,  the  new  view  may  net 
be  handled  with  good  machine  performance  tecause  the 
physical  structure  of  the  data  was  designed  to  best  serve 
the  most  common  applications .  The  physical  structure  is 
user-driven  even  if  the  logical  structure  is  not. 

The  advantage  of  relational  database  is  first  of 
all,  ease  of  use.  That  means  the  easiest  way  to  represent 
most  data  is  with  two  dimensional  tables.  Another  advantage 
is  flexibility.  Users  can  use  PROJECTION  and  JOIN  in  the 
form  they  want.  Another  advantage  is  precision.  This  means 
that  the  precise  results  of  relational  mathematics  can  be 
applied  to  the  manipulation  of  relations.  Computer  security 
is  another  important  application  area  where  the  relational 
model  should  be  considered.  Security  controls  can  be  easily 


5.5,  the  output  of  the  precompiler  is  then  input  to  a 
standard  languge  compiler  for  compilation  in  normal  fashion. 
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Figure  5.5  Role  of  SQL/CS  Precompiler 


4.  Advant^gj  §ad  Eisaivantagg  of  Relational  Database 

A  disadvantage  sometimes  cited  for  a  relational 
database  is  machine  performance.  With  present-day  hardware 


update  activities.  No  application  programming  is  required 
when  using  ISQL.  For  this  type  of  access,  users  must  be 
connected  to  a  communications  control  program  such  as  CICS 
or  equivalent. 

A  second  mode  of  access  is  via  application 
programs.  In  this  mode,  SQL/DS  commands  are  embedded  in 
standard  programming  text  like  COBOL,  PL/1,  or  assembler 
language.  These  embedded  commands  are  nearly  identical  to 
the  commands  that  are  issued  to  ISQL.  This  means  that 
application  programmers  need  learn  only  one  data  language; 
the  single  data  language  can  be  used  from  application 
programs  or  interactively  with  ISQL.  Users  claim  the  near 

identity  between  ISQL  statement  and  embedded  SOL/ES 

statements  helps  them  to  develop  application  programs. 
Programmers  can  develop  database  commands  interactively, 
verify  them  for  correctness  using  ISQL,  and  then  include 
those  commands  in  application  programs. 

Figure  5.5  shows  the  processing  of  embedded  SQL/CS 
statements.  Programs  containing  SQL/ES  commands  are  input  to 
a  precompiler  that  examines  the  statements  for  correctness 
and  builds  small  SQL/CS  access  modules  that  will  perform  the 
desired  database  service.  These  modules  are  stored  in  the 
database.  At  the  same  time,  program  instructions  are 
inserted  into  application  programs  to  call  the  stored  access 
modules  when  needed.  The  precompiler  generates  these 
instructions  in  standard  COBOL  or  ?L/1 .  As  shown  in  figure 
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user  to  process  data  without  concern  for  physical  data 
structures. 


There  are  many  other  relational  DBMS.  Figure  5.4 
lists  some  of  the  major  systems  as  of  late  1982.  There  is 
also  a  microcomputer  relational  product:  dBASF  II,  which 
operates  on  CP/M-based  micro.  dBASE  II  is  an  example  of  a 
relational  (or  tabular)  DBMS  that  restricts  join  operations. 
The  Join  columns  must  be  indexed. 

!  SQL-Based  System 

I 

!  SQL/DS,  IBM 

i 

!  ORACLE  ,  Relational  Software,  Inc. 

I 

!  System  Rf  IBM 

i 
i 

i  QUEL -Based  Systems 

I 

!  INGRES,  Relational  Technology,  Inc 

!  I  EM  500,  Britton-Lee, Inc 

i 
i 

i  Other  Relational  Systems 

i 

!  MRDS/LI NUS ,  Honeywell 

i 

i  dBASE  II,  Ashton-Tate 

i 
i 

!  NOMAD,  National  Compute  Sharing  Services 


Figure  5.4  Relational  DBMS  Products  and  Vender 

3 .  Two  Modes  of  Access  of  SQ^/DS 

SQL/DS  can  be  used  either  interactively  from  a 
terminal  or  via  application  programs.  The  interactive 
processor,  ISQL,  processes  SQL  commands  to  perform  query  and 


2.  Commercial  Relational  J)BMS 

There  are  currently  many  commercial  TEN'S  products 
that  claim  to  te  relational.  Some  are  more  relational  in 
name  than  in  actuality.  Criteria  can  be  used  to  assess 
whether  or  not  a  product  is  truly  a  relational  product. 
Specially,  the  EEMS  should  model  data  as  tables,  and  it 
should  support  SELECT,  PROJECT,  and  unrestricted  JOIN 
operati ons . 

Relational  DEMS  can  be  divided  into  three  groups. 
One  group  is  based  on  the  data  language  SQL,  one  on  the  data 
language  QUEL,  and  a  group  that  contains  systems  falling 
into  neither  of  these  categories. 

Three  major  SQL-based  DBMS  products  are  SQL/DS, 
System  R,  and  ORACLE.  System  R  is  a  research  system 
developed  by  IBM  for  the  study  of  relational  technology. 
ORACLE  is  vended  by  Relational  Software  Incorporated. 
Originally,  ORACLE  was  developed  for  operation  on  Digital 
Equipment  Corporation  ?DP  minicomputers.  Since  its  origin, 
ORACLE  has  teen  converted  to  operate  on  I3M  mainframes  as 
well.  ORACLE'S  user  interface  is  based  on  SEQUEL  II,  an 
earlier  version  of  SQL.  According  to  RSI,  ORACLE  will  soon 
te  compatible  with  the  current  version  of  SQL.  QUEL  is  a 


data  language  like  SQL.  (Just  like 

COBOL 

and 

PL/I 

a  re 

alternative 

programming  languages, 

SQL 

and 

QUEL 

are 

al terna  t i ve 

data  languages.)  QUEL 

is  based 

on 

tuple 

relati ona 1 

calculus.  QUEL  is  nonprocedual 

and 

allows 

the 
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nonpr cgrammer  users,  allowing  then  to  use  the  database 
without  resorting  to  computer-oriented  procedual  languages. 

1 .  Relational  Characteristics 

What  characteristics  must  a  DBMS  have  to  be 
considered  a  relational  product?  In  his  Turing  lecture, 

E.F  Codd  [Ref.  15]  defined  a  relational  DBMS  as  one  in 

which  data  is  defined  in  tables  and  processed  by  using 

SELECT,  PROJECT  and  unrestricted  JOIN  operations,  or  their 

equivalent.  Codd  called  a  system  having  these 

characteristics  MINIMALLY  RELATIONAL. 

■  SELECT,  PRODUCT,  and  JOIN  will  be  used  in  Chapter 
VI  .  The  SELECT  obtains  rows  of  the  table  according  to 
criteria  on  row  contents.  PROJECT  obtains  columns  of  a  table 
by  column  name.  Finally,  JOIN  brings  two  relations  together 
based  on  the  relationship  between  two  columns  having  the 
same  domain. 

Some  DBMS  products  specify  that  only  columns  can 
be  used  as  JOIN  criteria.  For  example,  a  DBMS  may  require 
the  columns  used  as  JOIN  criteria  to  be  indexed.  This 
implies  the  undesirable  situation  of  restricting  user 
activity  because  of  physical  data  re  resentation.  To  the 
nonspecialist  user,  this  restriction  appears  arbitrary.  In 
fact,  there  is  no  logical  reason  for  this  restriction;  it 
exists  only  to  improve  performance.  To  eliminate  this 
situation,  Codd  specifies  that  a  minimally  relational  system 
must  have  unrestricted  JOINS.  This  means  that  any  column  can 
be  used  as  criteria  for  the  JOIN. 


other  relations  are 


List  all  WPTC  file. 

•jpi>  select  • 

?  CPs'*  .»ofc; 


*C|_ 

*TV=E 

«»ANGE 

WFUEL 

6L0S 

ac 

I 

F3E 

1  0000 

800 

1  0000 

AC 

2 

F3E 

3000 

700 

15000 

AC 

i 

F3E 

5000 

500 

1  1000 

AC 

a 

FOO 

3000 

600 

1  1000 

AC 

5 

FOO 

1  1000 

800 

15000 

AC 

b 

FOD 

5000 

700 

12000 

SO 

i 

F3E 

30000 

50  0  0 

lOOOuO 

S-f 

2 

F  3E 

25000 

7000 

1  25000 

$-» 

3 

F3E 

1  5000 

6000 

1  1  0000 

5  o 

a 

FOO 

35000 

7000 

1  15000 

S-T 

5 

FOO 

2  0000 

8000 

1 30000 

SH 

b 

F  OD 

1  2000 

6000 

1  1  0000 

APU 

i 

F3E 

3500 

500 

5000 

AOU 

2 

F3E 

1000 

200 

2500 

AO(j 

3 

F  3E 

3000 

300 

0000 

AOU 

a 

FOO 

3  000 

600 

6000 

A  OiJ 

s 

F  70 

1000 

250 

3000 

APJ 

6 

F  70 

25  0  0 

500 

0500 

1?  rerords  id'ctei. 
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list  dll  PR  EC  fils 


UFI>  SELECT  • 

2  from  prec; 


poay 

PIO 

PCL 

PTtPE 

ONUW 

P*C 

■sot 

318 

AH(J 

1 

100 

FAl* 

SO  1 

318 

AH'.J 

3 

200 

F  A  t  R 

SOI 

316 

ARU 

5 

150 

FAIR 

502 

110 

AC 

1 

? 

PCLOV 

302 

208 

SH 

5 

4 

FAIR 

302 

101 

AC 

2 

8 

PCLDY 

302 

215 

SH 

3 

25 

PCL  OT 

302 

223 

SH 

3 

8 

pcloy 

302 

223 

SH 

1 

4 

PLCOY 

302 

303 

A'PlJ 

2 

200 

FAIR 

305 

1  10 

AC 

1 

10 

CLOY 

305 

223 

SH 

3 

4 

CLOY 

303 

31* 

A 

1 

200 

pcloy 

303 

231 

Sh 

6 

30 

CLOY 

14  records  selected. 


List  all  II'TE^P  file. 


UFI>  SELECT  . 

2  FROM  10TEMI*T 


no 

tCL 

I  Type 

101 

AC 

1 

101 

AC 

3 

110 

AC 

1 

110 

AC 

1 

1  10 

AC 

2 

1  1  0 

AC 

3 

2  08 

SH 

4 

208 

SH 

6 

318 

A9U 

1 

318 

A  R  J 

3 

318 

AC 

3 

305 

A3(J 

2 

2 1  5 

SH 

1 

215 

SH 

5 

215 

AC 

2 

10* 

AC 

4 

10* 

AC 

5 

223 

SH 

2 

225 

SH 

3 

223 

AC 

2 

3  1  6 

ARlj 

4 

316 

ABU 

5 

31b 

AC 

6 

231 

SH 

5 

231 

SH 

6 

231 

AC 

5 

records  selected 


List  all  ,aW  file 


UFt>  select  * 

2  f30«  A*; 


/ 


i«CL  4TYPE  A 


AC 

AC 

AC 

AC 

AC 

AC 

AC 

AC 

AC 

AC 

AC 

3i 

Si 

Si 

Si 

Si 

Si 

Si 

Si 

Si 

A  3  J 

A  3  J 

A3  J 

A  3  J 

A  3(J 

A3U 

A3U 

A3J 

A3U 

A  3'J 


1  A 

1  C 

2  A 

2  C 

3  A 
5  G 
a  k 

«  L 

5  K 

6  c 
6  P 
t  a 
l  E 

1  f 

2  E 

2  F 

3  r> 
«  m 
S  N 
h  M 
1  G 

1  H 

2  1 
3  H 
5  J 
a  p 
a  3 

5  P 
o  p 

6  P 


30  rffjaris  *«1ect*1. 


Several  sample  queries  and  the  results  using  OflACLE  are 
given  below. 

1.  List  what  V-inds  of  Installation  Classes  are  in  IPLC 

'JeI>  SELECT  UNI-iUE  (CLASS 

2  FPOM  [3F-; 


2.  List  how  many  Installation  ID  Codes  are  in  I RIC. 

UF I »  SELECT  COUNT(IIO) 

2  FROM  t-TECJ 

COUNT { 1 1 D ) 

10 


3.  List  Installation  record  file  sorted  by 
Installation  ID  Code  in  ascending'  order. 


UF I >  select  * 


2 

FROM  HE 

* 

3 

OBOES  SY 

T  io; 

rc 

no 

I  AREA 

IPERS 

IFF 

AF 

101 

a 

1500 

F0€ 

AF 

toa 

7 

1400 

FR9 

AF 

110 

10 

1600 

FOE 

PO 

200 

25 

4600 

FRO 

PS 

215 

32 

3900 

FOE 

P3 

223 

35 

S200 

FOE 

PO 

231 

30 

7500 

FRO 

A* 

303 

1 

900 

FOE 

AH 

316 

5 

3000 

FRO 

A  R 

316 

3 

2800 

FOE 

10  records  selected. 


4.  List  how  many  Friends  or  Foes  are  in  the 

Installation  records  where  the  IFF  is  equal  to  Foe. 


■JF !  >  SELECT  CDUNT(IFF) 

?  F9a*  IRF.; 

5  AH£B£  IF-  =  'FOE*; 

COUNT ( [EF1 
b 

5.  For  Installation  ID  Code  113,  display  the  weapons 
(Class/T.yoe )  observed  in  the  past  at  the  installation,  the 


Day  of  Photo  and  Number  of  Weapons  observed  which  correspond 


to  those  weapons  observed  In  the  past ,  ONLY  for  those 
weapons  with  a  maximum  ammo  load  in  excess  of  10,500  pounds. 


je  ! »  } 

1  SELECT  nrt-P.lCLiSS.tOTS^.ITfee.P^EC.anaY.PREC.PNUM 
?  ffiO«  I  )T  S"ftP  ,  ph£C  <  *H£C 
}  *h£pE  inr£«e.no  =  tin 
U  ftNO  I  HE^P  .  ICLftSS  S  P^EC.PCLftSS 

5  4nO  111E'J0  .  1  TYPE  s  =P£C.PIyB£ 
t,  anO  PP6C  .?CL»5S  =  /■*£:.  *CLft$S 

r  ft  NO  P-JPC.JTYP£  =  iP£C.-»IYPE 

A.  ft  NO  aPEC.nHS  >  TOSOO 


t:u 

»c 


r  rr3s 
2 


P04Y 

SO? 


PMJM 

A 


6.  Display  the  Installation  ID  Code  and  Area  for 
those  installations  photographed  on  Day  301  for  which  the 
weapons  (Class/Type)  observed  on  that  day  had  a  maximum 
range  In  excess  of  7,000  meters,  and  the  killing  radius  of 
all  ammunition  tyres  available  exceeds  125  feet. 


UFI»  ft 

1  SELECT  I PEC  . I  10, IPEC. I ftPf  ft 

2  -HO*'  HEC.PPtC.ftiHEC.aw.AHf; 

3  YHEPE  aprc.ftKlLL  »  125 

«  4N0  IftEC  ..iPftNoE  >  7000 

s  ft  no  PHfC.Hoar  =  301 

t  ftNO  IPEC. It-)  =  ppec.pio 
?*  ftNO  ft  N . ft  C  ft  T  r  SREC.ftCftT 


1  tl)  I  4P  £4 


31 A  ? 

3lA  ? 

31-5  S 


7.  Display  Installation  ID  Code  and  the  total  number 


of  weapons  observed  according  to  Installation  ID  Code, 


weapon  classes  ar.d  weapon  type. 


'.if i »  select  Pin,  Sim pnum) 

2  PPO«  PREC 

5  GROUP  3Y  P  1 0 . PCL  ASS . PT  r P£ ; 


®ro  sjR<Pv u«) 


101  ? 

110  17 

2P«  a 

21s  as 

22  3  '4 

22  5  1  2 

231  30 

303  200 

316  ISO 

3 1 S  300 

3  I P  200 

8.  Display  Installation  Class  and  Weapon  class  and 
Weapon  Type  and  the  total  nunber  of  Weapons  Observed,  where 
Installation  ID  Code  in  INSTALLATION  record  is  equal  to  that 
of  PHOTO  record  together  with  Installation  Class  and  Weapon 


class  and  Weapon  tyoe. 


UFI>  R 

1  SELECT  ICLASS,PCLASS,PTYPE#SUM(PNUW) 

2  FROM  IRECj PREC 

j  ohere  po  s  no 

«*  group  sir  iclass.pclass.ptype 


IC  PCu  pTtP*  SIJM(Onjm) 


AF  AC  1  (7 
AF  AC  2  8 
AR  ARy  1  300 
AR  ARU  2  200 
»a  AR'J  $  200 
A  R  ARJ  3  150 
Po  SH  1  a 
P3  SH  3  J7 
P3  SH  3  a 
P3  SH  i  3<i 

10  retsrii  selecte-j. 
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Display  Pday  of  Photo  for  any  day  that  Wrange  is 


greater  than  90p0,  Wlbs  is  greater  than  IP???  and  Wfeul  is 
602,  according  to  the  information  in  the  WRPC  record. 


U'l' 

UF1  * 

un> 

2 

5 

il 


5 

6 
7 


SELECT  UNIQUE  PDAY 

F»0**  i*REC.  prec 

•MERE  "RANGE  >  8000 
AND  AL3S  »  tOOOO 
AND  AF'JEL  >  800 
AND  aREC  . NCL  *SS  -  PREC.PCLASS 
ANO  aHEC.xTypE  =  PREC. “TYPE; 


PDAY 


502 

505 


10.  List  all  field  names  and  its  type  for  Photo 
record  . 


Uct>  QE  SCR  I  56  PRgC 


ae 

C  S  1  z  * 

t  yoe 

22 

ur) 

1  nunfic 

PDAY 

22 

an 

1  nunsric 

PJ1 

5 

? 

2  CMrAcrti- 

3  C  L  A  S  S 

32 

ao 

1  nj«tr  i  c 

P  7  Y  Rp 

22 

an 

1  rtjmer  i  c 

S 

j 

3  charge  t  e>- 

=  Air 

VII.  CONCLUSIONS  AND  SICQMMENM1IQNS 


An  Intelligence  Database  system  is  very  complex  and 
important,  and  needs  very  accurate  information  to  increase 
war  power. 

Manual  systems  can  not  reduce  national  defense 
expenditures  and  make  it  difficult  to  obtain  accurate 
information  from  the  Intelligence  system.  Thus,  database 
management  systems  must  be  used  in  Intelligence  systems  in 
order  to  increase  end-user  productivity,  decrease  staff, 
enable  work  to  be  done  more  efficiently,  and  permit  end-user 
management  more  authority  and  responsibility. 

Relational  database  models  will  be  most  useful  in 
Intelligence  systems,  because  this  model  gives  structural 
independence  for  the  database  and  a  high  level  language  for 
queries.  Normal  forms  and  query  optimization  techiniques  can 
be  applied  to  decrease  inefficiency  of  the  relational 
database  model  in  the  system  design  stage. 

When  we  design  a  database,  the  SPM  model  is  very 
important.  SDM  is  a  high-level  semantics-based  database 
description  and  structuring  formalism  for  the  database  and 
enhances  usability  of  the  database  system. 

The  output  of  SDM  is  a  specification  that  can  be  used 
to  implement  the  database  using  a  commercial  DBMS.  The 
output  of  SDM  has  two  alternatives.  If  we  are  going  to  use 


DBMS  based  on  the  relational  model,  we  will  produce  a 
relation  design.  If  ve  are  going  to  use  a  DBMS  based  on  the 
CODASTL  D5TG  model,  it  will  produce  a  DBTG  design. 

If  we  constructed  an  SDN  model,  it  would  be  easy  to 
reduce  the  effort  required  to  convert  elational  models  into 
DBTG  models  or  vice  versa. 

Using  the  output  of  SDN  in  the  Intelligence  system,  the 
records  are  rearranged  in  order  to  fit  a  relational  model, 
(e.g.,  creation  of  the  iaterrelational  constraints).  The 
ORACLE  DBMS  was  used  to  demonstrate  an  operative  relational 
DBMS.  The  ORACLE  database  management  system  is  a  good 
relational  database  model,  providing  a  user  friendly 
environment,  easy  to  use  and  fast  access  to  data. 

It  seems  appropriate  to  conclude  with  Codd's  statement 
of  the  objectives  for  the  relational  approach  [Ref. 12].  They 
are  as  follows: 

1.  To  provide  high  degree  of  data  independence. 

2.  To  provide  a  community  view  of  the  data  of  spartan 

simplicity,  so  that  a  wide  variety  of  users  in  an 

enterprise  can  interact  with  a  common  view  (while 

not  prohibiting  superimposed  user  views  for 
specialized  purposes). 

3.  To  simplify  the  potentially  f  rnidable  job  of  thr- 
database  administrator. 

4.  To  introduce  a  theoretical  foundation  into 


database  management. 


5.  To  merge  the  fact  retrieval  and  file  management 
fields  in  preparation  for  the  addition  at  a  later 
time  of  inferential  services  in  the  commercial 

world . 

5.  To  lift  database  application  programming  to  a  new 
level  -  a  level  in  which  sets  (and  more  specially 
relations)  are  treated  as  operands  instead  of 
being  processed  element  by  element. 

No  one  would  claim  that  all  these  objectives  have  now  been 
attained;  much  more  work  remains  to  be  done.  However,  a 
strong  foundation  has  been  established,  and  there  seem? 
good  reason  to  be  optimistic  about  the  eventual  outcome. 
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APPENDIX  A 


ORIGINAL  DATA 

Four  record  types  constitute  the  Intelligence  Database 
attached.  The  following  notes  and  definitions  apply  to  the 
database . 

1.  The  Installation,  Ammunition  and  Weapon  Records 
represent  the  status  as  of  the  end  of  day  300.  The  photo 
records  represent  information  obtained  on  the  indicated  day 
(not  neccessarily  in  addition  to  status  information  on  day 
300) . 

2.  Defintions 

Installation  Class  :  AE  -  airfields 

PC  -  ship  ports 
AR  -  Army  units 

Weapon  Class  :  AC  -  aircraft 
SH  -  ship 

APU  -  armour  unit  (eg.,  taniH 

Weapon  types  are  numbered  1,  2,  3,  4,  5,  6,  for 

ea  h  class 

Ammunition  categories  are  letters  A,P,C,r,F,T,C-, 

3.  The  occurence  of  the  database  as  given  is  assumed 
to  be  indicative  of  the  structure  in  the  determination,  of 
unique  keys,  record  relationships,  functional  dependencies, 
etc . 

4.  Variables  have  been  given  different  names  when 
they  appear  in  different  record  types.  (eg.,  IIR  and  PIT 
both  refer  to  Installation  ID  Code). 


5.  There  are  cases  where  repeating  group  data  is 
represented  on  the  page  of  a  particular  record  type.  (eg., 
Weapon  Class/Type  with  Installation  Records). 


INSTALLATION  RECORDS  (IREC) 


AMMUNITION  RECORDS  (AREC) 


ACAT 

ALBS 

AKILL 

A  WAR 

A 

410 

100 

1 

E 

175 

«-/ 

3 

C 

510 

150 

1 

D 

9  50 

500 

4 

I 

1100 

525 

4 

F 

1300 

500 

5 

G 

8 

1 

2 

H 

125 

2 

6 

I 

12 

1 

2 

J 

180 

100 

7 

K 

240 

125 

8 

L 

1450 

400 

9 

M 

1300 

500 

9 

N 

150 

2 

8 

0 

7 

1 

10 

ACAT  :  Ammo  Category 
ALBS  :  Weight  of  One  Round  (Pounds) 
AKILL  :  Killing  Radius  (Feet) 

AVAR  :  Warhead  Category 


PDAY  : 
PID  : 
PCLASS 
PTYPE 
PNUM  : 
PWC  : 


Pay  of  Photo 
Installation  Code 
:  Weapon  Class 
:  Weapon  Type 

Number  of  Weapons  Observed 
Weather  Condition 
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UNCLASSIFIED  F/G  9/2  NL 


END 


WEAPON  RECORDS  (PREC) 


W CLASS  WTYPE  WEF  WAMMO 


WRANGE  WFEUL 


WLES 


SCHEMA  name  is  Intelligence 
Record  name  is  IREC 


duplicates 

i  are  not 

allowed  for 

I  ID 

ICLASS 

type  is 

character 

2 

check  is 

equal  'AF', 

'A?', 

IIC 

type  is 

fixed 

t 

w 

IAREA 

type  is 

fixed 

2 

IPERS 

type  is 

fixed 

4 

IFF 

type  is 

character 

** 

check  is 

equal  'FOE' 

,  'FRD 

Record  name 

is 

PREC 

PDAT 

type  is 

fixed 

check  is 

less  than  366 

PID 

type  is 

fixed 

*1 

PCLASS 

type  is 

character 

•x 

PTTPE 

type  is 

fixed 

1 

PNUM 

type  is 

fixed 

3 

PVC 

type  is 

charac  ter 

5 

Record  name 

is 

AREC 

duplicates 

.  are  not 

allowed  for 

ACAT 

AC  AT 

type  is 

character 

1 

ALBS 

type  is 

fixed 

e 

AKILL 

type  is 

fixed 

3 

AVAR 

type  is 

fixed 

£ 

Record  name 

is 

VP.EC 

duplicates 

are  not 

allowed  fer 

V  C  L  A 

VCLASS 

type  is 

character 

WTYPE 

type  is 

fixed 

1 

VFF 

type  is 

charactrer 

«_ 

VRANGE 

type  is 

fixed 

5 

VFEUL 

type  is 

fixed 

4 

WLBS 

type  is 

fixed 

6 

Record  name 

is 

IDTEMP 

duplicates 

are  not 

allowed  for 

I ID ,  ICLASSS ,  ITYPE 

1 1 D 

type  is 

fixed 

7 

KJ 

ICLASS 

type  is 

character 

2 

check  is 

equal  'AC', 

'SH', 

I  TYPE 

type  is 

fixed 

1 

Record  name 

is 

AV 

dupl ica  tes 

i  are  not 

allowed  for 

VCLASS,  VTYPE,  VAMMO 

VCLASS 

type  is 

character 

'X 

VTYPE 

type  is 

fixed 

1 

VAMMO 

type  is 

character 

1 

Record  name 

is 

T NUMBER 

TDAY 

type  is 

fixed 

TPNUM 

type  is 

fixed 

4 

Figure  B.2  DBTG  Record  Schema  Description 


Order  is  sorted  by  defined  keys 
Member  is  IDTEMP 
Insertion  is  automatic 
Retention  is  fixed 

Check  is  IIC  in  IREC  =  IID  in  IDTEMP 

and  ICLASS  in  IREC  =  ICLASS  in  IDTEMP 
and  I  TYPE  in  IREC  =  ITYPE  in  IDTEMP 
Set  selection  is  by  value  of 
IID,  ITYPE,  ICLASS 
Set  name  is  AV_AR 
Owner  is  ~AW 

Order  is  sorted  by  defined  keys 
Member  is  AREC 
Insertion  is  automatic 
Retention  is  fixed 
Check  is  WAMMO  in  AW  =  ACAT  in  AREC 
Set  name  is  WR_AW 
Owner  is  WREC 

Order  is  sorted  by  defined  keys 
Member  is  AW 

Check  is  WCLASS  in  WREC  »  WCLASS  in  AW 
and  WTYPE  in  WREC  =  WTYPE  in  Aw 
Set  name  is  TOT  NUMBER 
Owner  is  PfiEC 
Order  is  last 
Member  is  T NUMBER 
Insertion  is  manual 
Retention  is  optional 

Check  is  PDAY  in  PREC  *  PDAY  in  T NUMBER 
Set  selection  is  by  value  of  PDAY 
Set  name  is  PR  IDTEMP 
Owner  is  PREC 
Order  is  last 
Member  is  IDTEMP 

Check  is  PID  in  PREC  =  IID  in  IDTEM? 

and  PCLASS  in  PREC  *  ICLASS  in  IDTEM? 
and  PTYPE  in  PREC  =  ITYPE  in  IDTEMP 
Set  selection  is  by  value  of 
PID,  PCLASS,  PTYPE 
Set  name  is  IDTEMP_AW 

duplicates  are  not  allowed  for  WCLASS, WTYPE 
Owner  is  IDTEMP 

Order  is  sorted  by  defined  keys 
Member  is  AW 

Check  is  ICLASS  in  IDTEMP  =  WCLASS  in  AW 
and  ITYPE  in  IDTEM?  =  WTYPE  in  AW 


Fig  B.3  DBTG  Schema  Description  for  Intelligence 


Fagin,  Ronald.  A  Normal  Form  for^Relati onal  Database 
That  Is  Based  on  Domains  and  Keys.”  In  Transaction  on 
Database  Systems,  Vol.6,  No. 3,  Septem^e r“TS?I 

Coda,  E.F.  "Relational  Database:  A  Practical  Foundation 
for  Productivity."  In  Communications  of  the  AC^,  Vol. 
25,  No.  2,  February  1982. 
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